Re: Speeding up Interrupts...
:> > #FD9F: called 50/60 times per second, :> >a restard-command to stop the diskdrive. :> >- before disabling this call, I will call it 256 times after :> > a diskoperation to stop the drive. :> :> LD A,1 :> LD (#F1C1),A :> CALL #FD9F :> :> Should be enough, you don't need to call it 256 times. : :What is this adress about (#F1C1) ? - I never heard from it before. :An undocumented adress? But it seems to be "dangerous" because :of its location in the memory... Yes, I would like to know about that too... Won't it give trouble when the A:-drive isn't the diskdrive but, for example, a harddisk? To me it seems that this adress is in the area where the BDOS keeps its FCBs etcetera... ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
At 05:55 PM 10/19/98 +0200, you wrote: >I want to speed up the interrupt (original #38). >So I use the #FD9A for jumping to my own routine (which will >pop the return-adress from the stack), checking the Vertcal- >Blank flag and only the absoult necessary things. There is a much more convenient way of doing this: select RAM in the #-#3FFF area and write your own interrupt handler at #38. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
> ; --- Switch to own ISR > > di > ldHL,#C000; start address of jump-table is #C000 > ldDE,#C001 > ldBC,256-1 > ld(HL),#D0; start address of ISR is #D0D0 > ldir Correction: use "ld BC,256". If the data bus contains #FF, #C0FF and #C100 will be read, so you need 257 values. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: speeding up interrupts
] I figured out this approach to stopping disk drive motor(s, note ] there might still be another drive running, if you start this game ] quickly enough from a different one): ] ]LD IX,#4029 ]LD IY,(#F347) ]CALL #001C ] --- snip ] ] But: on using this myself, I found these drawbacks: There is one other drawback: The MSX turbo R has a bug in this routine when running under DOS2. Because of this bug, it sometimes hangs itself up. I whish those people had done a better job when designing that machine. There are a number of design flaws and bugs like this one... Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: speeding up interrupts
> ] But: on using this myself, I found these drawbacks: > There is one other drawback: The MSX turbo R has a bug in this routine when > running under DOS2. Because of this bug, it sometimes hangs itself up. > > I whish those people had done a better job when designing that machine. There > are a number of design flaws and bugs like this one... Can you please tell us more about these bugs and things, that we should not do ? ,_. _=_=_=_=!_MSX_!=_=_=_=_=_=_=_=_, ! A1ST ~--- - I ( o o o o o o )i /`, / .::;::; ., / :::.:.:.::::!. -=- `, ~== NYYRIKKI : [EMAIL PROTECTED] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
:Maarten ter Huurne schrieb: : :> >I want to speed up the interrupt (original #38). :> >So I use the #FD9A for jumping to my own routine (which will :> >pop the return-adress from the stack), checking the Vertcal- :> >Blank flag and only the absoult necessary things. :> :> There is a much more convenient way of doing this: select RAM in the :> #-#3FFF area and write your own interrupt handler at #38. : :I thought to get problems by using the DOS2-mapper routines if :ROM isn't selected in page 0. When in Dos, does page 0 (=#-#4000) contain ROM? Not, so it won't give trouble either as long as you select the ROM at the official way. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
On Mon, 19 Oct 1998, Oberleithner Wolfgang wrote: > I want to speed up the interrupt (original #38). > So I use the #FD9A for jumping to my own routine (which will > pop the return-adress from the stack), checking the Vertcal- > Blank flag and only the absoult necessary things. There is no absolut necessary things, if you are not trying to run some multitasking proggram (like MoonBlaster replayer) Ofcource BIOS routines can't be used, if you select RAM to area #-#3FFF, so you have to make your own keyboard reading routines etc. if you need them. > #FD9F: called 50/60 times per second, >a restard-command to stop the diskdrive. >- before disabling this call, I will call it 256 times after > a diskoperation to stop the drive. LD A,1 LD (#F1C1),A CALL #FD9F Should be enough, you don't need to call it 256 times. > What is your opinion? Will I be in troubles by removing this two calls? No. ,_. _=_=_=_=!_MSX_!=_=_=_=_=_=_=_=_, ! A1ST ~--- - I ( o o o o o o )i /`, / .::;::; ., / :::.:.:.::::!. -=- `, ~== NYYRIKKI : [EMAIL PROTECTED] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Speeding up Interrupts...
Hello! I want to speed up the interrupt (original #38). So I use the #FD9A for jumping to my own routine (which will pop the return-adress from the stack), checking the Vertcal- Blank flag and only the absoult necessary things. Everything is fine, BUT - there are still two things which I would like to remove... the call to the old #FD9A, and the call to #FD9F. #FD9A: called on every interrupt which occurs, normally not used by the system, only some special software. - there shouldn't be problems if I won't call this old entry #FD9F: called 50/60 times per second, a restard-command to stop the diskdrive. - before disabling this call, I will call it 256 times after a diskoperation to stop the drive. What is your opinion? Will I be in troubles by removing this two calls? thanx in advance for your help greets wolfgang -- Chief-Gavaman Programmers' Affair - The Vampyre of MSX Empire> http://www.myworld.privateweb.at/gavaman/default.html MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
On Mon, 19 Oct 1998, Maarten ter Huurne wrote:
> There is a much more convenient way of doing this: select RAM in the
> #-#3FFF area and write your own interrupt handler at #38.
>
Sure, this is what I'm doing in my new software, "Music Station".
For those who don't know, "Music Station" ("MUST" for short) is a
player for the new audio file format, WVZ .
The WVZ allows reproduction of 4-bit PCM with a high storage rate,
30 seconds per megabit. The current implementation of MUST requires a
MSX-1 with a brazilian MegaRAM. Since most MegaRAMs in Brazil have 256kb,
most users will be able to play musics with one minute of audio!!
Users who don't have a MegaRAM can use the emulator "brmsx" to
test MUST. A new version, with support for the Memory Mapper, will be
released in the Jau98+ meeting.
The home page of MUST is still under construction, but you can
download the software from:
http://www.lsi.usp.br/~ricardo/must.htm
Ricardo Bittencourt http://www.lsi.usp.br/~ricardo
[EMAIL PROTECTED]"Save the trees: eat more woodpeckers"
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: speeding up interrupts
On Thu, 22 Oct 1998, Alwin Henseler wrote: > About stopping the diskdrive after disk actions: Thanx, that you explained this. >LD IX,#4029 >LD IY,(#F347) >CALL #001C No, no no !!! Don't use this. First time, when I used a proggram, that used this call, it turned off my HDD, and throwwed my Zip-disk straight out of drive and it hitted to the ground... After that I placed my Zip-drive to different location on my table. :-) > I would say calling the hook at FD9Fh 256 times (do yourself a favor, > no less than 256..), is by far the best, AND most > compatible/problem-free way of shutting down disk-drives and such. Yeah, U R right... Sorry, that I mentioned this bad idea... ,_. _=_=_=_=!_MSX_!=_=_=_=_=_=_=_=_, ! A1ST ~--- - I ( o o o o o o )i /`, / .::;::; ., / :::.:.:.::::!. -=- `, ~== NYYRIKKI : [EMAIL PROTECTED] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
NYYRIKKI schrieb: > > #FD9F: called 50/60 times per second, > >a restard-command to stop the diskdrive. > >- before disabling this call, I will call it 256 times after > > a diskoperation to stop the drive. > > LD A,1 > LD (#F1C1),A > CALL #FD9F > > Should be enough, you don't need to call it 256 times. What is this adress about (#F1C1) ? - I never heard from it before. An undocumented adress? But it seems to be "dangerous" because of its location in the memory... wolfgang -- Chief-Gavaman Programmers' Affair - The Vampyre of MSX Empire <___ACTIVE - GROUP___>> http://www.myworld.privateweb.at/gavaman/default.html MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
Maarten ter Huurne schrieb: > >I want to speed up the interrupt (original #38). > >So I use the #FD9A for jumping to my own routine (which will > >pop the return-adress from the stack), checking the Vertcal- > >Blank flag and only the absoult necessary things. > > There is a much more convenient way of doing this: select RAM in the > #-#3FFF area and write your own interrupt handler at #38. I thought to get problems by using the DOS2-mapper routines if ROM isn't selected in page 0. wolfgang -- Chief-Gavaman Programmers' Affair - The Vampyre of MSX Empire <___ACTIVE - GROUP___>> http://www.myworld.privateweb.at/gavaman/default.html MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
Response of own-interrupt-expert Grauw... Oberleithner Wolfgang wrote: :I want to speed up the interrupt (original #38). :So I use the #FD9A for jumping to my own routine (which will :pop the return-adress from the stack), checking the Vertcal- :Blank flag and only the absoult necessary things. If in DOS I'd advice you to hook adress #38. That is much faster and also more 'compatible'. Hooking adress #FD9A might cause diffuculty when using an other (new) BIOS... Which for example might have an additional PUSH AF before the call to the hook... Which will give problems. If you are programming a game or so I'd suggest you switch RAM in slot 0 (who uses the bios?) or use another interrupt-mode (IM 2, if I'm correct. Don't forget to switch back to IM1 afterwards!). :Everything is fine, BUT - there are still two things which :I would like to remove... :the call to the old #FD9A, and the call to #FD9F. The gain in speed is very minimal compared to the advantages. :#FD9A: called on every interrupt which occurs, : normally not used by the system, only some special software. : - there shouldn't be problems if I won't call this old entry Used by the newest version of MBWAVE and its basic-replayer. :#FD9F: called 50/60 times per second, : a restard-command to stop the diskdrive. : - before disabling this call, I will call it 256 times after : a diskoperation to stop the drive. Used by MBWAVE < v1.1 and MB1.4-songs Also, the stop of the drive isn't really 'good' when you call it 256 times after a diskoperation, it will STOP. Immediately after every disk-access. Which isn't that nice... :What is your opinion? Will I be in troubles by removing this two calls? No troubles, I think, but some things might not work correct anymore. In my own interrupt-routines, I always call #FD9A and if it's an VDP-interrupt I also call #FD9F, fill in the key-table, increase JIFFY and do some game-related things. But I dunno if you can speed-up the interrupt that much. Yes, I know your thinking... You hope to be able to delete some PUSH and POP-instructions at the beginning. Well, when you really, REALLY need the speed, then you might delete the calls to #FD9A and #FD9F. But if you have got a music-routine on the interrupt, you still have no gain, for then you still have to push all registers. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
>Hello! > > >I want to speed up the interrupt (original #38). >So I use the #FD9A for jumping to my own routine (which will >pop the return-adress from the stack), checking the Vertcal- >Blank flag and only the absoult necessary things. > >Everything is fine, BUT - there are still two things which >I would like to remove... > >the call to the old #FD9A, and the call to #FD9F. > >#FD9A: called on every interrupt which occurs, > normally not used by the system, only some special software. > - there shouldn't be problems if I won't call this old entry > >#FD9F: called 50/60 times per second, > a restard-command to stop the diskdrive. > - before disabling this call, I will call it 256 times after > a diskoperation to stop the drive. > >What is your opinion? Will I be in troubles by removing this two calls? > > >thanx in advance for your help > >greets >wolfgang > > You can also create your own ISR, using another Interrupt Mode of the Z80. The good side of *this* method is that you still can use the BIOS routines. Let me show you how to do it: - Create a jumptable, starting at a 256-byte boundary (i.e. #C000, #C100, etc), containing 128 times the start-address of your ISR-routine. Note that the high- and low-byte of this address should be the same (for safety). (i.e. #D0D0, #CFCF, etc.). - Put the high-byte of the start-address of the jumptable in the interrupt-vector register (i.e.: LD A,#C0 LD I,A). - Switch to interrupt-mode 2. Here's an example: ; --- Switch to own ISR di ldHL,#C000; start address of jump-table is #C000 ldDE,#C001 ldBC,256-1 ld(HL),#D0; start address of ISR is #D0D0 ldir ldA,#C0; let interrupt-vector point to #C0xx ldI,A ; (xx = variable!!!) im 2; Interrupt Mode 2 ei equ #D0D0 ISR: ; your ISR This code is from the top of my head, but I think this'll do. Note that you took over the complete ISR! So, save the registers onto the stack yourself, check whether it's a VDP Vertical Retrace interrupt, etc. Also you have to take care of keyboard-input yourself. No default handler will do that for you anymore, since these handlers run under interrupt as well. Hope this helps! Greets, Jan-Lieuwe Koopmans MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
> > >I want to speed up the interrupt (original #38). > > >So I use the #FD9A for jumping to my own routine (which will > > >pop the return-adress from the stack), checking the Vertcal- > > >Blank flag and only the absoult necessary things. > > > > There is a much more convenient way of doing this: select RAM in the > > #-#3FFF area and write your own interrupt handler at #38. > > I thought to get problems by using the DOS2-mapper routines if > ROM isn't selected in page 0. I never tried to keep my custom BIOS operating during disk actions. If I wanted to do that, I would have to program a lot of subroutines apart from the interrupt handler. (ENASLT, CALSLT etc.) During disk actions, you don't really need an efficient interrupt handler, because interrupts will be disabled most of the time anyway. Simply switch to ROM for disk actions and back to RAM afterwards. To turn off the drive, you can use the trick Nyyrikki described, although it is not 100% nice. He uses the default address for the disk motor counter, but it is not guaranteed that the counter will be there. There is a more safe way, I will look it up. Note that I have never seen a machine on which his trick doesn't work, but I haven't seen every single MSX model so there might exist one. I once made a very compatible way of stopping diskdrive motors. It worked too well: on some harddisk interfaces, it stopped the harddisk from spinning! I think it did stop the harddisk on Novaxis, but didn't stop it on a Bert. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: speeding up interrupts
Hi, About stopping the diskdrive after disk actions: This particular address mentioned earlier contains a drive-off counter. It is set to, I think, 254, after every disk action, and decreased 1 on every call to the diskROM's interrupt handler (so every timing-interrupt). If it reaches zero (so after some 5 seconds), the drive motor is stopped. If THIS drive is accessed again in the meanwhile, the interval starts again. The value 255 has a special meaning: 'keep running'. If you do something with the drive, and POKE 255 in this memory location quickly (before the counter reaches zero), this diskdrive motor simply keeps running. The address is simply the same on many MSX machines, because they use similar working diskROM(s), but it is NOT a fixed address in any way, not documented, not guaranteed or such, in one word: don't rely on something like this, if you do, someone will have troubles because of it, some other time. I figured out this approach to stopping disk drive motor(s, note there might still be another drive running, if you start this game quickly enough from a different one): LD IX,#4029 LD IY,(#F347) CALL #001C This is a call to a diskROM entry, which (should) contain a routine that 'scans' all diskROMs, and calls another entry in each, which should be present in each diskROM, to stop the drive. The address F348h contains the slot-address of the 'main' diskROM (the first one, that handles the initialising stuff and so on), the address 4029h is one of a small number of entries present in any diskROM, and are described in the MSX Technical Databook (I'm not sure if they're also in the MSX2 Tech Handbook). You can call the method above pretty solid, and it should work whenever there IS a diskdrive (contents of FFA7h<>C9h). But: on using this myself, I found these drawbacks: -It stops DRIVE-motors, doesn't do anything with other interrupt-related processes that might be running. -On my Novaxis SCSI, it stopped the HDD motor as well (great, mine made a lot of noise). But those stupids from Gouda did implement this diskROM-entry, but forgot to turn on the drive again when accessed, in case it was shut down this way (! stupid, stupid...) So, shutdown the drives this way, and you'd have to reset the machine again, just to get the HDD spinning again (I switched it on and off instead). -This diskROM-entry might not be (properly, or not at all) implemented with a particular disk system I would say calling the hook at FD9Fh 256 times (do yourself a favor, no less than 256..), is by far the best, AND most compatible/problem-free way of shutting down disk-drives and such. I'd say this IM2 approach is not a bad idea (and yes, there need to be 257 of the same values on the address I*256), it prevents you from HAVING to switch RAM in page 0, and you can select a different starting address for your interrupt routine, which is called immediately on each interrupt, rather than having to wait for a few instructions at #0038 to get executed first, before a hook-address is called. If you'd switch RAM in page 0, you'd also have to setup at least the slotswitching-routines, which are the same under DOS, BASIC, and even present in MSX-2 subROM. I'd say, a lot of work. Best way would be to use this IM2-approach during run-time, using all 'common' hardware (VDP, keyboard etc.) by direct I/O (remember any BIOS call might re-enable interrupts, and mess up things when you'd expect these to be off at that time), and temporarily switching back to IM1, and restoring memory settings etc. when making any BIOS or disk CALLs. Your program might have a setup like this: On startup: -Store any memory settings, in case you need to change, and restore these later (other initialisation) -Set up your interrupt handler -Set up this 257 byte table (interrupt handler at address 257*fillbyte), starting at a 256-byte boundary (low byte 0) -Set Z80 I-register to the high byte of the address of this table -switch to IM 2 -enter a main loop of your program On a disk-access/BIOS-call: -restore memory settings, if needed, possibly update some system memory locations containing VDP-register contents and so forth -switch back to IM 1 -make your BIOS/disk CALL -(.. make some more disk CALLs) -call FD9Fh 256 times -switch to IM 2 again On exit: -Do the same restoring as before -Switch back to IM 1 If that still doesn't do it: -Use a faster METHOD of obtaining your goal -Write even faster code -make a turbo-circuit (6/7 MHz. or my own) a system requirement -or make it a TurboR program Greetings, Alwin Henseler([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx(MSX Tech Doc page) http://www.twente.nl/~cce/index.htm(Computerclub Enschede) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/m
Re: Speeding up Interrupts...
> Response of own-interrupt-expert Grauw... > > If you are programming a game or so I'd suggest you switch RAM in slot 0 > (who uses the bios?) or use another interrupt-mode (IM 2, if I'm correct. > Don't forget to switch back to IM1 afterwards!). Yes, it's IM2. But it's not that easy to use. IM2 works like this: - interrupt register contains high byte of entry in interrupt vector table - at the time of an interrupt, the data bus contains low byte of entry in interrupt vector table In the interrupt vector table, an address is read and that is where will be jumped to (begin of interrupt handler). Most MSX systems have #FF on the databus at the time of an interrupt, but I heard (from one of the NOP members) that some cartridges mess with this, so you cannot be sure. The safe way is to store the same value in a 257 byte long range like #4000-#4101 and set the I register to #40 in this example. If the value stored is #41, #4141 will always be the address. But I think a custom BIOS is much easier to use, unless you plan to use BIOS routines. > :#FD9A: called on every interrupt which occurs, > : normally not used by the system, only some special software. > : - there shouldn't be problems if I won't call this old entry > > Used by the newest version of MBWAVE and its basic-replayer. But your custom BIOS can call the MBWAVE replayer directly, if you use it. > Also, the stop of the drive isn't really 'good' when you call it 256 times > after a diskoperation, it will STOP. Immediately after every disk-access. > Which isn't that nice... That's true, you have to stop the drive after every block of disk actions. Another thing to remember: if you need disk swapping in your game and you run under DOS2, be sure to invalidate the disk buffers before every block of disk actions. There is a DOS2 call that does this. Otherwise, the disk change will not be detected on most machines. On non-turbo-R, DOS2 'detects' disk change simply by counting the time since the last disk action. It is assumed that no-one can swap a disk in less than a second (or another small time interval). If you stop calling #FD9F, the counting stops and DOS2 can think the last disk action was very recent but in fact several minutes have passed since. > :What is your opinion? Will I be in troubles by removing this two calls? > > No troubles, I think, but some things might not work correct anymore. Isn't that a form of trouble? > In my own interrupt-routines, I always call #FD9A and if it's an > VDP-interrupt I also call #FD9F, fill in the key-table, increase JIFFY and > do some game-related things. > > But I dunno if you can speed-up the interrupt that much. > Yes, I know your thinking... You hope to be able to delete some PUSH and > POP-instructions at the beginning. The real speed gain comes from: - Not filling the key-table: games are usually interested in only a few keys, not the whole keyboard. Besides, why not read the keyboard directly from your game? - Keeping VDP status register 2 enabled all of the time. Or register 1, if you use line interrupts frequently. This doesn't make your interrupt routine faster, but it can speed up your non-interrupt code. - Not decreasing the disk drive counter, which requires a slow inter-slot-call. - No writing to the joystick registers of the PSG. If you omit that, you will be able to use the JoyNet without disabling interrupts. So you gain speed not by doing the same in less time, but by doing less. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
