GPL Gate
ok, I've been thinking about how to call the GPL interpreter from ROM space without having 32K memory expansion.
I want to have a gate into GPL from my spectra2 library. I'm still not certain if it's even worth the effort.
Actually I was mainly interested in the GPL COINC instruction (Sprite/tile colission detection).
But it seems you can only have your mapping tables in GROM so that won't really help me now.
Since this is all about having fun, I thought what the heck.
EDIT: I now have an own thread for the GPL Gate here.
2
SPECTRA2 development thread
Started by retroclouds, Aug 14 2010 2:12 PM
107 replies to this topic
#27 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Sun Sep 19, 2010 3:11 AM
scratch-pad memory usage (update 3)
I came up with some small modifications to the memory setup again.
For storing the spectra2 configuration flags, I've decided to use a register in favour of a memory location.
At the same time I'm moving the cursor YX position from that register into the freed memory location.
Reason for this change is that bit flags need to be tested against a register anyway. So I'm now saving a "MOV" operation.
I also moved the virtual game keyboard flags (E) from a register into a memory location. Wait a minute, didn't I just did
the exact opposite thing for the configuration flags? Yes, that's true. The thing is that I need a free register for storing
other more important flags. See the updated register usage.
The decision of what goes into a register or memory location, depends on what will be used most often and where (at various
code spots, ...)
Here's the new memory layout:
register usage (update 1)
I've got some changes to the register usage. Here are the latest updates:
!important!
There is a comprehensive set of equates available for addressing all of the below registers. It is strongly advised you use these equates where possible.
It'll allow register reorganization without you having to modify your program big time.
There are also equates available for accessing the high/low bytes of any of the mentioned registers.
A) General purpose registers (R0-R3)
You can use the registers R0-R3 in your subroutines without any worry. spectra2 will not affect those registers.
B) Temporary registers (R4-R7)
These registers can be used for storing temporary values. You have to consider that they likely will be overwritten if you
call any of the spectra2 routines. So, it's a good idea to store register values on the stack or in R0-R3 before
calling a routine.
Please use the TMP0..TMP3 equates instead of R4-R7. The registers may be reorganized at a later time. But you are safe if you use TMP0..TMP3
C) Stack pointer (R8)
Pointer to both subroutine return stack and data stack. The stack pointer is set by the spectra2 initialisation routine.
For debugging purposes you could set the data stack equate to another register, e.g. R7
D) Address of return routine (R9)
The address is is set by the spectra2 initialisation routine. It points to the M3POPR machine code in scratch-pad memory.
For exiting a nested subroutine a "B *R9" is to be used.
Benefit: opcode size is only 2 bytes instead of 6 bytes when using "B @>xxxx". Will also be used when a return accross ROM memory banks is required.
E) Highest slot in use & internal counter for timers (R10)
The high byte of R10 keeps track of the highest slot used in the timer table.
The low byte of R10 is the timer tick counter and is updated every 1/50th or 1/60th of a second.
F) Subroutine return address (R11)
Same use as in Editor/Assembler. Contains the return address when doing "BL xxxx"
G) SPECTRA2 configuration register
Flags for controlling and checking various features of the library and your TI-99/4A console.
H) Copy of VDP status register and internal counter for sound list (R13)
The high byte of R13 contains a copy of the VDP status register. This byte is automatically updated by the timer manager.
The low byte of R13 contains an internal counter used by the sound player.
I) Copy of VDP register #0 and VDP register #1 bytes(R14)
This is new in spectra2. In SPECTRA1 a copy of the values in VDP write-only registers 0-7 was present in scratch-pad RAM.
To save memory, this feature was rejected in SPECTRA2. It's now returning but only for VDP write-only registers 0-1 as these control
most of the features of the VDP.
J) VDP write address (R15)
Contains the address of the VDP data window. The address is set by the spectra2 initialisation routine.
This register is heavily used by the built-in functions responsible for VDP communication.
I came up with some small modifications to the memory setup again.
For storing the spectra2 configuration flags, I've decided to use a register in favour of a memory location.
At the same time I'm moving the cursor YX position from that register into the freed memory location.
Reason for this change is that bit flags need to be tested against a register anyway. So I'm now saving a "MOV" operation.
I also moved the virtual game keyboard flags (E) from a register into a memory location. Wait a minute, didn't I just did
the exact opposite thing for the configuration flags? Yes, that's true. The thing is that I need a free register for storing
other more important flags. See the updated register usage.
The decision of what goes into a register or memory location, depends on what will be used most often and where (at various
code spots, ...)
Here's the new memory layout:
A) Register workspace
That's obvious right? On the TMS9900 CPU we need a workspace in memory to hold the 16 registers.
B) Address of timer table
We can now have multiple timer tables and the timer table can also be relocated. This offers more flexibility compared to the original
SPECTRA implementation where we only had a fixed address.
C) Address of sound table (tune)
The built-in sound player will be compatible with the ISR sound format. The tune can either be in VDP memory or ROM/RAM.
This is controlled by one of the bits in (D).
D) Cursor YX position
This is new in spectra2. We'll have some functions you can use to put tiles & text at specific coordinates
without you having to calculate each individual position.
E) Virtual game keyboard flags or keycodes
Already had the concept of a virtual game keyboard in SPECTRA1.
The idea is that we have a keyboard (including mapping to joysticks) and each bit represents a game key.
Most likely there will be an additional keyboard scan routine that can hold the typed key and a status flag.
F) Loop code + return from stack
This is new in SPECTRA2. It contains some machine code that is copied from ROM on library startup.
We can easily modify the machine code during runtime by overwriting some of the opcodes.
register usage (update 1)
I've got some changes to the register usage. Here are the latest updates:
!important!
There is a comprehensive set of equates available for addressing all of the below registers. It is strongly advised you use these equates where possible.
It'll allow register reorganization without you having to modify your program big time.
There are also equates available for accessing the high/low bytes of any of the mentioned registers.
registers Purpose ========= ============================================================ R0-R3 A General purpose registers R4-R7 B Temporary registers R8 C Return stack and data stack pointer R9 D Address of return routine (M3POPR) R10 E Highest slot in use + Timer counter R11 F Subroutine return address R12 G SPECTRA2 configuration register R13 H Copy of VDP status byte and internal counter for sound player R14 I Copy of VDP write-only register #0 and #1 R15 J VDP write address =============================================================================
A) General purpose registers (R0-R3)
You can use the registers R0-R3 in your subroutines without any worry. spectra2 will not affect those registers.
B) Temporary registers (R4-R7)
These registers can be used for storing temporary values. You have to consider that they likely will be overwritten if you
call any of the spectra2 routines. So, it's a good idea to store register values on the stack or in R0-R3 before
calling a routine.
Please use the TMP0..TMP3 equates instead of R4-R7. The registers may be reorganized at a later time. But you are safe if you use TMP0..TMP3
C) Stack pointer (R8)
Pointer to both subroutine return stack and data stack. The stack pointer is set by the spectra2 initialisation routine.
For debugging purposes you could set the data stack equate to another register, e.g. R7
D) Address of return routine (R9)
The address is is set by the spectra2 initialisation routine. It points to the M3POPR machine code in scratch-pad memory.
For exiting a nested subroutine a "B *R9" is to be used.
Benefit: opcode size is only 2 bytes instead of 6 bytes when using "B @>xxxx". Will also be used when a return accross ROM memory banks is required.
E) Highest slot in use & internal counter for timers (R10)
The high byte of R10 keeps track of the highest slot used in the timer table.
The low byte of R10 is the timer tick counter and is updated every 1/50th or 1/60th of a second.
F) Subroutine return address (R11)
Same use as in Editor/Assembler. Contains the return address when doing "BL xxxx"
G) SPECTRA2 configuration register
Flags for controlling and checking various features of the library and your TI-99/4A console.
H) Copy of VDP status register and internal counter for sound list (R13)
The high byte of R13 contains a copy of the VDP status register. This byte is automatically updated by the timer manager.
The low byte of R13 contains an internal counter used by the sound player.
I) Copy of VDP register #0 and VDP register #1 bytes(R14)
This is new in spectra2. In SPECTRA1 a copy of the values in VDP write-only registers 0-7 was present in scratch-pad RAM.
To save memory, this feature was rejected in SPECTRA2. It's now returning but only for VDP write-only registers 0-1 as these control
most of the features of the VDP.
J) VDP write address (R15)
Contains the address of the VDP data window. The address is set by the spectra2 initialisation routine.
This register is heavily used by the built-in functions responsible for VDP communication.
Edited by retroclouds, Sun Sep 19, 2010 3:13 AM.
#28 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Sun Sep 19, 2010 8:49 AM
Configuration register
The configuration register will be used to set/check various options of the spectra2 environment and the TI-99/4A machine it runs on.
Here's an overview:
The flags 0-3 will be automatically set when the kernel is initialized.
You can use flags 8-15 to control several spectra2 options while the kernel is running.
The configuration register will be used to set/check various options of the spectra2 environment and the TI-99/4A machine it runs on.
Here's an overview:
bit 15 Sound player tune source 1=ROM/RAM 0=VDP MEMORY bit 14 <<free>> bit 13 <<free>> bit 12 Keyboard mode 1=real 0=virtual bit 11 <<free> bit 10 Timer has hyperthread 1=yes 0=no bit 9 <<free> bit 8 <<free> bit 7 <<free> bit 6 <<free> bit 5 <<free> bit 4 <<free> bit 3 V2.2 console 1=yes 0=no bit 2 Speech synth present 1=yes 0=no bit 1 VDP9918 PAL version 1=yes(50) 0=no(60) bit 0 32K memory expansion 1=yes 0=no
The flags 0-3 will be automatically set when the kernel is initialized.
You can use flags 8-15 to control several spectra2 options while the kernel is running.
#29 OFFLINE
Opry99er
-
-
- 3,434 posts
River Patroller
- Location:Denver, CO
Posted Fri Sep 24, 2010 5:07 PM
Filip... I tried to access your most recent SPECTRA2 documents on ninerpedia but couldn't seem to view them. I am experiencing a bit of web difficulty but I can see other sites. Can you post a file here?
#30 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Sat Sep 25, 2010 2:29 AM
Opry99er, on Fri Sep 24, 2010 5:07 PM, said:
Filip... I tried to access your most recent SPECTRA2 documents on ninerpedia but couldn't seem to view them. I am experiencing a bit of web difficulty but I can see other sites. Can you post a file here?
Owen, perhaps the site was down for a short period. Just tried and it works now.
Also did some quick updates. Unfortunately my documentation is lagging behind again.
I've done quite some changes, so I really should be doing some documentation updates now.
#31 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Sun Sep 26, 2010 10:47 AM
Configuration register (update 1)
Some adjustment to the config flags. Here's the current overview:
The flags 0-3 will be automatically set when the kernel is initialized.
You can use flags 8-15 to control several spectra2 options while the kernel is running.
Bit 13-15 are used to control the sound player. The sound player uses 4 bytes of scratchpad CPU memory.
If bit 13=0 you can use these 4 bytes for other purposes, even when the player code is running.
Notice bit 11. I'm planning on having a routine for automatic sprite motion.
The motion table can be either in VRAM or RAM. I'll also need a pointer in scratchpad memory pointing to the table.
The pointer will be stored next to the pointer for the sound list. If automatic sprite motion isn't used you'll be
able to use these 2 bytes for other purposes as well.
I really have to update my scratchpad memory map.
Some adjustment to the config flags. Here's the current overview:
bit 15 Sound player: Tune source 1=ROM/RAM 0=VDP MEMORY bit 14 Sound player: Loop tune 1=yes 0=no bit 13 Sound player: on 1=yes 0=no (or pause) bit 12 ASM: Motion Table source 1=ROM/RAM 0=VDP MEMORY bit 11 ASM: Automatic Sprite Motion on 1=yes 0=no bit 10 Timer has fast thread 1=yes 0=no bit 9 <<free> bit 8 <<free> bit 7 <<free> bit 6 <<free> bit 5 <<free> bit 4 <<free> bit 3 V2.2 console 1=yes 0=no bit 2 Speech synth present 1=yes 0=no bit 1 VDP9918 PAL version 1=yes(50) 0=no(60) bit 0 32K memory expansion 1=yes 0=no
The flags 0-3 will be automatically set when the kernel is initialized.
You can use flags 8-15 to control several spectra2 options while the kernel is running.
Bit 13-15 are used to control the sound player. The sound player uses 4 bytes of scratchpad CPU memory.
If bit 13=0 you can use these 4 bytes for other purposes, even when the player code is running.
Notice bit 11. I'm planning on having a routine for automatic sprite motion.
The motion table can be either in VRAM or RAM. I'll also need a pointer in scratchpad memory pointing to the table.
The pointer will be stored next to the pointer for the sound list. If automatic sprite motion isn't used you'll be
able to use these 2 bytes for other purposes as well.
I really have to update my scratchpad memory map.
Edited by retroclouds, Sun Sep 26, 2010 10:48 AM.
#32 OFFLINE
Opry99er
-
-
- 3,434 posts
River Patroller
- Location:Denver, CO
Posted Tue Sep 28, 2010 12:03 AM
This is coming along nicely. 
I am amazed by how much you can cram into such a small bit of RAM!!!! Truly,
economy of space on the TI has come to it's pinnacle with SPECTRA2. I'm itching to get the full docs and package and start working!!!
I am amazed by how much you can cram into such a small bit of RAM!!!! Truly,economy of space on the TI has come to it's pinnacle with SPECTRA2. I'm itching to get the full docs and package and start working!!!
#33 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Tue Sep 28, 2010 4:48 AM
Opry99er, on Tue Sep 28, 2010 12:03 AM, said:
This is coming along nicely. I am amazed by how much you can cram into such a small bit of RAM!!!! Truly,
economy of space on the TI has come to it's pinnacle with SPECTRA2. I'm itching to get the full docs and package and start working!!!
I am amazed by how much you can cram into such a small bit of RAM!!!! Truly,economy of space on the TI has come to it's pinnacle with SPECTRA2. I'm itching to get the full docs and package and start working!!!
Thanks. A major difference compared to my first trial with SPECTRA1, is that I'm making extensive use
of the register space and at the same I'm reducing stack usage a lot by avoiding push/pop where I can.
I pretty much completed the feature list for the first release. There is still a lot to do, but we're getting there
#34 OFFLINE
sometimes99er
-
-
- 2,307 posts
River Patroller
- Location:Denmark
Posted Tue Sep 28, 2010 6:24 AM
Here are my thoughts in relation to 8K+ game development and my Strawberry cartridge output.
Sound. I think it's pretty essential to game development to have independent control of music and soundeffects (also soundeffects like lasers and explosions occurring at the same time or overlapping). I'd definitely go for 3 sources, but 2 would be fine too. As long as Strawberry tries to cope with TI Basic, one source is fine, but there are plans for easy bulk loads of graphics, color, maps, arrays, sound, music and speech.
As for game development I'd rather control the sprites myself. Collision detection, when, where, how and why is pretty individual as I see it. I might even go so far as not supporting automotion (as we know it) with Strawberry.
Timers. I think I understand the benefits of threading. I think I would do fine with the "old" game loops and occasional spreading of task over frames. Like with my "Secret Scroll" demo, when I prepare the scroll of the entire screen over 8 frames. Classic99 doesn't run this very smooth. Win994a runs pretty smooth. MESS can be made to run smooth (synchronizing things). I guess a timer could count to 8 and do the different parts. Also I guess your system supports some kind of prioritizing. Turning things on and off are also nice. I usually do that using control bits/variables.
The other bits are very nice to have, but did you consider methods returning the state instead. Then you wouldn't need allocate ScrathPad. If I'm "already running" on a V2.2, then fine, but I wouldn't use the information. Speech is probably the most useful. Speech routines could return CPU if not attached. With Speech and 32K one could quit if not present, or ask nicely for the devices to be attached(/selected). I don't see myself doing something I wouldn't do just because the 32K is available. I mean, I've already coded what I want with either ScratchPad only or 32K in mind.
Generally I don't care for GPL and/or disk operations. I think they tend to mess things up a bit. I feel I haven't even begun to explore within the 8K limit, and since 64K and 256K bankswitching are becoming available, and maybe soon even GROM as placeholder for further data, and all in a true to original design/console style, - well, then I don't "have time to look back" (at GPL or disk). You know you have to concentrate/know your niche sometimes.
Sorry if any of this sounds negative. It's only supposed to be constructive input. The decisions with Spectra are yours. Also, I am of course putting these things forward since I could be interested in using Spectra with both game development, demos and Strawberry.
I know Mark has custom speech running on the interrupt, and I've glanced his code, and failed somewhat at my previous attempts. Would be nice if you would add routines for dealing with interrupt driven speech.
Does the assembler only incorporate Spectra routines that are referenced in the user code ? Or what assembler are you using ?
Take care.
Sound. I think it's pretty essential to game development to have independent control of music and soundeffects (also soundeffects like lasers and explosions occurring at the same time or overlapping). I'd definitely go for 3 sources, but 2 would be fine too. As long as Strawberry tries to cope with TI Basic, one source is fine, but there are plans for easy bulk loads of graphics, color, maps, arrays, sound, music and speech.
As for game development I'd rather control the sprites myself. Collision detection, when, where, how and why is pretty individual as I see it. I might even go so far as not supporting automotion (as we know it) with Strawberry.
Timers. I think I understand the benefits of threading. I think I would do fine with the "old" game loops and occasional spreading of task over frames. Like with my "Secret Scroll" demo, when I prepare the scroll of the entire screen over 8 frames. Classic99 doesn't run this very smooth. Win994a runs pretty smooth. MESS can be made to run smooth (synchronizing things). I guess a timer could count to 8 and do the different parts. Also I guess your system supports some kind of prioritizing. Turning things on and off are also nice. I usually do that using control bits/variables.
The other bits are very nice to have, but did you consider methods returning the state instead. Then you wouldn't need allocate ScrathPad. If I'm "already running" on a V2.2, then fine, but I wouldn't use the information. Speech is probably the most useful. Speech routines could return CPU if not attached. With Speech and 32K one could quit if not present, or ask nicely for the devices to be attached(/selected). I don't see myself doing something I wouldn't do just because the 32K is available. I mean, I've already coded what I want with either ScratchPad only or 32K in mind.
Generally I don't care for GPL and/or disk operations. I think they tend to mess things up a bit. I feel I haven't even begun to explore within the 8K limit, and since 64K and 256K bankswitching are becoming available, and maybe soon even GROM as placeholder for further data, and all in a true to original design/console style, - well, then I don't "have time to look back" (at GPL or disk). You know you have to concentrate/know your niche sometimes.
Sorry if any of this sounds negative. It's only supposed to be constructive input. The decisions with Spectra are yours. Also, I am of course putting these things forward since I could be interested in using Spectra with both game development, demos and Strawberry.
I know Mark has custom speech running on the interrupt, and I've glanced his code, and failed somewhat at my previous attempts. Would be nice if you would add routines for dealing with interrupt driven speech.
Does the assembler only incorporate Spectra routines that are referenced in the user code ? Or what assembler are you using ?
Take care.
Edited by sometimes99er, Tue Sep 28, 2010 6:36 AM.
#35 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Tue Sep 28, 2010 1:07 PM
Thanks for your feedback. I really do appreciate it. First of all, it's not sounding negative so no worries
Well, due to the fact that my documentation is lagging behind a bit and also because I didn't release anything yet,
there might be some questions on what spectra2 will be.
I have a pretty clear picture of what I want spectra2 to become. So let me go through the details.
Basically spectra2 will act like a miniature OS for the unexpanded TI-99/4A. It's specifically designed
for running new games from the cartridge space with only having 256 bytes of scratch-pad memory to your disposal.
What it definitely will not be, is a collection of high-level routines for things as pixel scrolling, super duper graphic effects, etc.
As mentioned before, the thing is that such high-level routines abstract too much and also put too many
constraints on the developer. I'll leave it up to the imagination of the developer for implementing such routines
Spectra2 concentrates on some of the low level stuff and also provides a program structure
you can use in your games. In other words, you don't have to start from scratch.
Utility
* Bank-switching routine
* random generator
* ...
I/O low level
* Routines for copying memory: CPU memory<->VDP memory, GROM->VDP memory, GROM->CPU memory, etc.
* RLE decompression to CPU memory, VDP memory
* Implementation of a "virtual game keyboard". Basically a routine that scans the keyboard matrix and does the required mapping on a virtual game keyboard. That way you for example do not specifically have to check if joystick 1 was moved left or key 'S' was pressed.
Timers
* Scheduler for running "threads" synchronized by the VDP interrupt. A very important part of the library.
I see this more as a design pattern really.
* Possiblity to run isolated threads outside the VDP memory window. This is meant for tasks that do not need any VRAM access.
e.g. do calculations, speech, ...
Graphics
* Possibility to load a video mode table
* Dispaying tiles in a box, show text at certain position, ...
* Support for multiple VDP PNT base addresses.
*Sprite Automation support
* Collision detection
Sound & speech
* A sound player with a sound format that is compatible to the ISR sound player.
It currently supports sounds lists stored in ROM/RAM and VRAM. With the recent hardware development, I am seriously
considering adding GROM as sound source.
* Speech player with support for data stored in CPU memory, GROM. Not sure if playing from VDP memory would be possible
Still have to investigate on that.
Regarding to your remarks. I think we aren't that far apart
Myelf I'm the kind of developer that hardly uses any libraries at all, unless I write them myself.
It's kinda hard to find the right balance of how far one has to go in the support functions.
If you want full controll, then yes it's best to handle everything yourself.
At the same time for new TMS9900 assembly developers having such functions is indeed a help.
That is why I spent quite some time thinking how I can offer best of both worlds.
By that I mean if you don't want to use a function, then it shouldn't clutter memory or take (too much) ROM memory.
Also I try having the same calling convention in all my subroutines.
This means I can either call a function with DATA parameter or pass parameters via registers.
As far as GPL is concerned. I have given that some more thought this week and I have decided that the functionality will
not be included in the default runtime library. It's putting too many constraints on scratch-pad memory
for being useful. I'm not dumping the idea, because with the GROM support in development one could write his own
GPL program for doing basic program setup, etc. The code is there, so I'll probably wrap it in an optional library.
As far as disk access is concerned; If all turns out well I might get some help from someone who is very talented in
that area. I'm not interested in floppy disk access. But with all those CF7+ and nanopebs floating arround it would
be cool to have some support for it.
You have a good point about targetting your audience, e.g. why would I do something differently just because I have 32K
memory to my disposal. Perhaps we'll see a few of the flags go, in favour of other control flags
The idea for speech, is that you run the speech player as a thread. This is the same way I've implemented the sound player.
Regarding the assembler; I'm currently still using winasm as cross assembler. I've started working on "booster", my custom assembler.
But that project has to wait until spectra2 is done.
Well, due to the fact that my documentation is lagging behind a bit and also because I didn't release anything yet,
there might be some questions on what spectra2 will be.
I have a pretty clear picture of what I want spectra2 to become. So let me go through the details.
Basically spectra2 will act like a miniature OS for the unexpanded TI-99/4A. It's specifically designed
for running new games from the cartridge space with only having 256 bytes of scratch-pad memory to your disposal.
What it definitely will not be, is a collection of high-level routines for things as pixel scrolling, super duper graphic effects, etc.
As mentioned before, the thing is that such high-level routines abstract too much and also put too many
constraints on the developer. I'll leave it up to the imagination of the developer for implementing such routines
Spectra2 concentrates on some of the low level stuff and also provides a program structure
you can use in your games. In other words, you don't have to start from scratch.
Utility
* Bank-switching routine
* random generator
* ...
I/O low level
* Routines for copying memory: CPU memory<->VDP memory, GROM->VDP memory, GROM->CPU memory, etc.
* RLE decompression to CPU memory, VDP memory
* Implementation of a "virtual game keyboard". Basically a routine that scans the keyboard matrix and does the required mapping on a virtual game keyboard. That way you for example do not specifically have to check if joystick 1 was moved left or key 'S' was pressed.
Timers
* Scheduler for running "threads" synchronized by the VDP interrupt. A very important part of the library.
I see this more as a design pattern really.
* Possiblity to run isolated threads outside the VDP memory window. This is meant for tasks that do not need any VRAM access.
e.g. do calculations, speech, ...
Graphics
* Possibility to load a video mode table
* Dispaying tiles in a box, show text at certain position, ...
* Support for multiple VDP PNT base addresses.
*
* Collision detection
Sound & speech
* A sound player with a sound format that is compatible to the ISR sound player.
It currently supports sounds lists stored in ROM/RAM and VRAM. With the recent hardware development, I am seriously
considering adding GROM as sound source.
* Speech player with support for data stored in CPU memory, GROM. Not sure if playing from VDP memory would be possible
Still have to investigate on that.
Regarding to your remarks. I think we aren't that far apart
Myelf I'm the kind of developer that hardly uses any libraries at all, unless I write them myself.
It's kinda hard to find the right balance of how far one has to go in the support functions.
If you want full controll, then yes it's best to handle everything yourself.
At the same time for new TMS9900 assembly developers having such functions is indeed a help.
That is why I spent quite some time thinking how I can offer best of both worlds.
By that I mean if you don't want to use a function, then it shouldn't clutter memory or take (too much) ROM memory.
Also I try having the same calling convention in all my subroutines.
This means I can either call a function with DATA parameter or pass parameters via registers.
As far as GPL is concerned. I have given that some more thought this week and I have decided that the functionality will
not be included in the default runtime library. It's putting too many constraints on scratch-pad memory
for being useful. I'm not dumping the idea, because with the GROM support in development one could write his own
GPL program for doing basic program setup, etc. The code is there, so I'll probably wrap it in an optional library.
As far as disk access is concerned; If all turns out well I might get some help from someone who is very talented in
that area. I'm not interested in floppy disk access. But with all those CF7+ and nanopebs floating arround it would
be cool to have some support for it.
You have a good point about targetting your audience, e.g. why would I do something differently just because I have 32K
memory to my disposal. Perhaps we'll see a few of the flags go, in favour of other control flags
The idea for speech, is that you run the speech player as a thread. This is the same way I've implemented the sound player.
Regarding the assembler; I'm currently still using winasm as cross assembler. I've started working on "booster", my custom assembler.
But that project has to wait until spectra2 is done.
#36 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Tue Sep 28, 2010 1:24 PM
Here's a minimal example for a thread.
The example shows a blinking "Hello World" on the screen.
Here's the 8K rom image
hw.zip 2.08K
8 downloads
Comes with no warranties, I only tried it in classic99
The example shows a blinking "Hello World" on the screen.
********@*****@*********************@************************** AORG >6000 *-------------------------------------------------------------- * Cartridge header *-------------------------------------------------------------- GRMHDR BYTE >AA,1,1,0,0,0 DATA PROG BYTE 0,0,0,0,0,0,0,0 PROG DATA 0 DATA KERNEL HW BYTE 12 TEXT 'HELLO WORLD!' *-------------------------------------------------------------- * Include required files *-------------------------------------------------------------- COPY "F:\Projekte\spectra2\tms9900\runlib.a99" *************************************************************** * Main ********@*****@*********************@************************** MAIN BL @FILV DATA >0380,>F0,16 ; Set color table BL @LDFONT DATA >900 ; Load title screen font LI R0,>8370 MOV R0,@WTIMER ; Our timer table BL @MKSLOT DATA >000F,BLINK,0 ; thread in slot 0 must run every 15 ticks MOVB @BDIG1,@>8369 B @TMGR ; Run thread scheduler *************************************************************** * Thread ********@*****@*********************@************************** BLINK MOV R11,R0 ; Save NEG @>8368 JLT BLIN2 BLIN1 BL @PUTYX DATA >050A,HW ; Show "Hello World!" message JMP BLIN3 BLIN2 BL @HCHAR BYTE >05,>0A,32,12 ; white space x BLIN3 MOV R0,R11 ; Restore B *R11 END
Here's the 8K rom image
hw.zip 2.08K
8 downloadsComes with no warranties, I only tried it in classic99
#37 OFFLINE
sometimes99er
-
-
- 2,307 posts
River Patroller
- Location:Denmark
Posted Tue Sep 28, 2010 1:49 PM
Thanks for feedback.
I can't get the rom image to work. Nothing shows up on the menu selection screen. - I don't think it's this, but sure you're not generally missing an EVEN after the TEXT ?
Regarding "outside the VDP memory window". You're not saying that the CPU can't access the VDP outside this window ? (see post #24)
I can't get the rom image to work. Nothing shows up on the menu selection screen. - I don't think it's this, but sure you're not generally missing an EVEN after the TEXT ?
Regarding "outside the VDP memory window". You're not saying that the CPU can't access the VDP outside this window ? (see post #24)
#38 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Wed Sep 29, 2010 11:18 AM
sometimes99er, on Tue Sep 28, 2010 1:49 PM, said:
Thanks for feedback.
I can't get the rom image to work. Nothing shows up on the menu selection screen. - I don't think it's this, but sure you're not generally missing an EVEN after the TEXT ?
Regarding "outside the VDP memory window". You're not saying that the CPU can't access the VDP outside this window ? (see post #24)
I can't get the rom image to work. Nothing shows up on the menu selection screen. - I don't think it's this, but sure you're not generally missing an EVEN after the TEXT ?
Regarding "outside the VDP memory window". You're not saying that the CPU can't access the VDP outside this window ? (see post #24)
ok, it took me a moment to figure out why this didn't work in MESS. The problem is not the ROM image itself.
The problem is that the filename of the rom image in the rpk file is "invalid". I created a layout.xml with the below definition and it didn't work.
<?xml version="1.0" encoding="utf-8"?> <romset version="1.0"> <resources> <rom id="romimage1" file="hw.bin"/> </resources> <configuration> <pcb type="standard"> <socket id="rom_socket" uses="romimage1"/> </pcb> </configuration> </romset>
The strange thing is that I checked the ROM area at >6000 using the memory editor of the MESS debugger and I could see my program was there.
However the TI-99/4A could not find it. I just renamed the rom image file to hwc.bin and changed the layout.xml accordingly, et voila
Still, I think that's a bug in MESS. It should fully rely on the name as specified in the rom tag of the XML.
I've updated my zip file accordingly.
Edited by retroclouds, Wed Sep 29, 2010 11:22 AM.
#39 OFFLINE
sometimes99er
-
-
- 2,307 posts
River Patroller
- Location:Denmark
Posted Wed Sep 29, 2010 11:19 AM
Oh my, guess it was just about renaming hw.bin to hwc.bin. Nice example. Thanks.
#40 OFFLINE
sometimes99er
-
-
- 2,307 posts
River Patroller
- Location:Denmark
Posted Wed Sep 29, 2010 11:25 AM
retroclouds, on Wed Sep 29, 2010 11:18 AM, said:
The strange thing is that I checked the ROM area at >6000 using the memory editor of the MESS debugger and I could see my program was there.
However the TI-99/4A could not find it. I just renamed the rom image file to hwc.bin and changed the layout.xml accordingly.
However the TI-99/4A could not find it. I just renamed the rom image file to hwc.bin and changed the layout.xml accordingly.
#41 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Wed Oct 6, 2010 1:20 PM
scratch-pad memory usage (update 4)
I did some changes to the memory layout today. I thought that I should have everything stabilized by now.
That's true for the most part, but some modifications were necessary. So let's take a closer look.
The memory locations are now aligned in such way that they can be reused if some of the functions aren't used
(e.g. keyboard scanning or sound player).
register usage (update 2)
Yes, I'm changing register allocation again. Here are the latest updates.
!important!
There is a comprehensive set of equates available for addressing all of the below registers. It is strongly advised you use these equates where possible.
It'll allow register reorganization without you having to modify your program big time.
There are also equates available for accessing the high/low bytes of any of the mentioned registers.
A) General purpose registers (R0-R3)
You can use the registers R0-R3 in your subroutines without any worry. spectra2 will not affect those registers.
B) Temporary registers (R4-R8)
These registers can be used for storing temporary values. You have to consider that they likely will be overwritten if you
call any of the spectra2 routines. So, it's a good idea to store register values on the stack or in R0-R3 before
calling a routine.
Please use the TMP0..TMP4 equates instead of R4-R8. The registers may be reorganized at a later time. But you are safe if you use TMP0..TMP4
C) Stack pointer (R9)
The stack pointer is set by the spectra2 initialisation routine.
D) Highest slot in use & internal counter for timers (R10)
The high byte of R10 keeps track of the highest slot used in the timer table.
The low byte of R10 is the timer tick counter and is updated every 1/50th or 1/60th of a second.
E) Subroutine return address (R11)
Same use as in Editor/Assembler. Contains the return address when doing "BL xxxx"
F) SPECTRA2 configuration register
Flags for controlling and checking various features of the library and your TI-99/4A console.
G) Copy of VDP status register and internal counter for sound list (R13)
The high byte of R13 contains a copy of the VDP status register. This byte is automatically updated by the timer manager.
The low byte of R13 contains an internal counter used by the sound player.
H) Copy of VDP register #0 and VDP register #1 bytes(R14)
This is new in spectra2. In SPECTRA1 a copy of the values in VDP write-only registers 0-7 was present in scratch-pad RAM.
To save memory, this feature was rejected in SPECTRA2. It's now returning but only for VDP write-only registers 0-1 as these control most of the features of the VDP.
I) VDP write address (R15)
Contains the address of the VDP data window. The address is set by the spectra2 initialisation routine.
This register is heavily used by the built-in functions responsible for VDP communication.
I did some changes to the memory layout today. I thought that I should have everything stabilized by now.
That's true for the most part, but some modifications were necessary. So let's take a closer look.
A) Register workspace
That's obvious right? On the TMS9900 CPU we need a workspace in memory to hold the 16 registers.
B) Loop code
This is new in SPECTRA2. It contains some machine code that is copied from ROM on library startup.
We can easily modify the machine code during runtime by overwriting some of the opcodes.
I dropped the part that is responsible for returning from the stack. This saves 4 bytes.
C) Address of timer table
We can now have multiple timer tables and the timer table can also be relocated. This offers more flexibility compared to the original
SPECTRA implementation where we only had a fixed address.
D) PNT base address **new**
This is new in spectra2. It contains the base address of the pattern name table.
We can set the value here and then use it in several derived calculations.
E) Cursor YX position
This is new in spectra2. We'll have some functions you can use to put tiles & text at specific coordinates
without you having to calculate each individual position.
F) Virtual game keyboard flags or keycodes
Already had the concept of a virtual game keyboard in SPECTRA1.
The idea is that we have a keyboard (including mapping to joysticks) and each bit represents a game key.
Most likely there will be an additional keyboard scan routine that can hold the typed key and a status flag.
G) Sound player - Address of sound table (tune)
The built-in sound player will be compatible with the ISR sound format. The tune can either be in VDP memory or ROM/RAM.
This is controlled by one of the bits in (D).
H) Sound player - temporary use **new**
2 bytes required while running the sound player. By using these bytes I enhance the functionality of the sound player.
It's now possible to loop a tune or chain multiple tunes.
The memory locations are now aligned in such way that they can be reused if some of the functions aren't used
(e.g. keyboard scanning or sound player).
register usage (update 2)
Yes, I'm changing register allocation again. Here are the latest updates.
!important!
There is a comprehensive set of equates available for addressing all of the below registers. It is strongly advised you use these equates where possible.
It'll allow register reorganization without you having to modify your program big time.
There are also equates available for accessing the high/low bytes of any of the mentioned registers.
registers Purpose ========= ============================================================ R0-R3 A General purpose registers R4-R8 B Temporary registers R9 C Stack pointer R10 E Highest slot in use + Timer counter R11 F Subroutine return address R12 G SPECTRA2 configuration register R13 H Copy of VDP status byte and internal counter for sound player R14 I Copy of VDP write-only register #0 and #1 R15 J VDP write address =============================================================================
A) General purpose registers (R0-R3)
You can use the registers R0-R3 in your subroutines without any worry. spectra2 will not affect those registers.
B) Temporary registers (R4-R8)
These registers can be used for storing temporary values. You have to consider that they likely will be overwritten if you
call any of the spectra2 routines. So, it's a good idea to store register values on the stack or in R0-R3 before
calling a routine.
Please use the TMP0..TMP4 equates instead of R4-R8. The registers may be reorganized at a later time. But you are safe if you use TMP0..TMP4
C) Stack pointer (R9)
The stack pointer is set by the spectra2 initialisation routine.
D) Highest slot in use & internal counter for timers (R10)
The high byte of R10 keeps track of the highest slot used in the timer table.
The low byte of R10 is the timer tick counter and is updated every 1/50th or 1/60th of a second.
E) Subroutine return address (R11)
Same use as in Editor/Assembler. Contains the return address when doing "BL xxxx"
F) SPECTRA2 configuration register
Flags for controlling and checking various features of the library and your TI-99/4A console.
G) Copy of VDP status register and internal counter for sound list (R13)
The high byte of R13 contains a copy of the VDP status register. This byte is automatically updated by the timer manager.
The low byte of R13 contains an internal counter used by the sound player.
H) Copy of VDP register #0 and VDP register #1 bytes(R14)
This is new in spectra2. In SPECTRA1 a copy of the values in VDP write-only registers 0-7 was present in scratch-pad RAM.
To save memory, this feature was rejected in SPECTRA2. It's now returning but only for VDP write-only registers 0-1 as these control most of the features of the VDP.
I) VDP write address (R15)
Contains the address of the VDP data window. The address is set by the spectra2 initialisation routine.
This register is heavily used by the built-in functions responsible for VDP communication.
#42 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Wed Oct 6, 2010 1:58 PM
The main modification done to the register usage, is basically adding an additional temporary register TMP4 (R8).
I shifted the stack pointer from R8 to R9 while dropping the original usage of R9 (address of return routine).
We now have the temporary register TMP4 to our disposal and this further reduces the need for stack manipulation.
The goal is that the routines in spectra2 won't require any stack usage at all.
You'll also notice that I grouped most of the memory variables into "memory area 2".
This means that if you are not using stuff like the virtual keyboard or built-in sound player, you'll have 12 additional bytes to your disposal.
Current status of the project is that I have the virtual keyboard working, but some further debugging will be necessary.
Next up are speech synthesizer support and some pending utility routines. After that we should be ready for a first official release.
It's about time because I wanna go back to actual game development
I shifted the stack pointer from R8 to R9 while dropping the original usage of R9 (address of return routine).
We now have the temporary register TMP4 to our disposal and this further reduces the need for stack manipulation.
The goal is that the routines in spectra2 won't require any stack usage at all.
You'll also notice that I grouped most of the memory variables into "memory area 2".
This means that if you are not using stuff like the virtual keyboard or built-in sound player, you'll have 12 additional bytes to your disposal.
Current status of the project is that I have the virtual keyboard working, but some further debugging will be necessary.
Next up are speech synthesizer support and some pending utility routines. After that we should be ready for a first official release.
It's about time because I wanna go back to actual game development
Edited by retroclouds, Wed Oct 6, 2010 2:20 PM.
#43 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Thu Oct 7, 2010 1:52 AM
No auto-sprite movement! Say what ?!!
This morning I woke up and it was clear that I'm not gonna implement auto-sprite movement. There are several reasons for that.
Moving sprites in a linear way is not what I have in mind when I think about advanced games.
Sure, they're ok for Frogger style games (in that case I would go for a tile based solution instead of sprite based one though).
I also don't want to re-implement Extended Basic functionality, so I'll leave the moving of sprites to the developer.
The way it looks I'll be making some more changes to the memory layout again. If you go through the development thread, you'll notice there were a lot of changes to the memory layout lately. This layout is very important because after doing the initial release I can't change it much anymore. Also something that looks perfectly clear at one moment, makes you wonder just a few days or weeks later.
The memory allocation changes I have to do, are mainly related to the thread scheduler. In one of my earlier posts I mentioned that
R0-R3 will be available to the developer without having to worry that spectra2 messes with those registers.
Well the thread scheduler does exactly that. It means if you run anything as a thread and use R0-R3 you have to push/pop them to the stack.
As threads are a core concept of spectra2 and I don't want the push/pop overhead, I have to change the implementation of the thread scheduler, hence the memory changes.
All in all I'm pretty pleased with the results so far. I have been giving this project a lot of thought in the last few months.
It's like a big puzzle and I have to fit the pieces together in such way that the routines work in an efficient way in terms of memory and code size. The library may not use more than 64 bytes of scratchpad memory and 2000 bytes of ROM.
A few bytes of RAM could be spared by using some clever equates. I'm already using equates where possible. However in this case it's a tradeof. It would cost both flexibility and make it a lot harder for the developer to actually use the library.
I think I have found a good balance between memory requirements and flexibility.
For new developers it means they just include the "runlib.a99" file and are ready to start writing games that run from the cartridge space
with a built-in sound/speech player and virtual keyboard to your disposal.
Advanced programmers are still available to override core functionaly, by changing two pointers in scratchpad memory.
I've also decided that I won't be using any of the routines that are in the monitor OS. Reasons for that are the way scratchpad memory needs to be setup in order to do monitor calls. The only thing I will be accessing from the (g)roms in the TI-99/4A is the character set data.
I've also still have to implement the trampoline code, this will also take a few bytes of scratch-pad memory in "memory area 2" (the optional memory ara). It means if you're not using bank-switching you'll have that memory to your disposal as well.
That's it for now folks
This morning I woke up and it was clear that I'm not gonna implement auto-sprite movement. There are several reasons for that.
Moving sprites in a linear way is not what I have in mind when I think about advanced games.
Sure, they're ok for Frogger style games (in that case I would go for a tile based solution instead of sprite based one though).
I also don't want to re-implement Extended Basic functionality, so I'll leave the moving of sprites to the developer.
The way it looks I'll be making some more changes to the memory layout again. If you go through the development thread, you'll notice there were a lot of changes to the memory layout lately. This layout is very important because after doing the initial release I can't change it much anymore. Also something that looks perfectly clear at one moment, makes you wonder just a few days or weeks later.
The memory allocation changes I have to do, are mainly related to the thread scheduler. In one of my earlier posts I mentioned that
R0-R3 will be available to the developer without having to worry that spectra2 messes with those registers.
Well the thread scheduler does exactly that. It means if you run anything as a thread and use R0-R3 you have to push/pop them to the stack.
As threads are a core concept of spectra2 and I don't want the push/pop overhead, I have to change the implementation of the thread scheduler, hence the memory changes.
All in all I'm pretty pleased with the results so far. I have been giving this project a lot of thought in the last few months.
It's like a big puzzle and I have to fit the pieces together in such way that the routines work in an efficient way in terms of memory and code size. The library may not use more than 64 bytes of scratchpad memory and 2000 bytes of ROM.
A few bytes of RAM could be spared by using some clever equates. I'm already using equates where possible. However in this case it's a tradeof. It would cost both flexibility and make it a lot harder for the developer to actually use the library.
I think I have found a good balance between memory requirements and flexibility.
For new developers it means they just include the "runlib.a99" file and are ready to start writing games that run from the cartridge space
with a built-in sound/speech player and virtual keyboard to your disposal.
Advanced programmers are still available to override core functionaly, by changing two pointers in scratchpad memory.
I've also decided that I won't be using any of the routines that are in the monitor OS. Reasons for that are the way scratchpad memory needs to be setup in order to do monitor calls. The only thing I will be accessing from the (g)roms in the TI-99/4A is the character set data.
I've also still have to implement the trampoline code, this will also take a few bytes of scratch-pad memory in "memory area 2" (the optional memory ara). It means if you're not using bank-switching you'll have that memory to your disposal as well.
That's it for now folks
#44 OFFLINE
Willsy
-
-
- 1,220 posts
Stargunner
- Location:Uzbekistan (no, really!)
Posted Fri Oct 8, 2010 11:46 AM
retroclouds, on Thu Oct 7, 2010 1:52 AM, said:
A few bytes of RAM could be spared by using some clever equates. I'm already using equates where possible.
Indeed!
TurboForth actually refers to the same memory locations under different names in some parts of the code. This is because, under some circumstances, routines can share memory addresses (say, for temporary storage) without interfering with each other. For example, the Editor stores its X & Y coordinates in the same place as the cursor coordinates for the command line system, since, upon exit from the editor, the screen is cleared, zeroing the X & Y for the command line. Thus, they can happily share the same memory address.
It's possible to refer to the same memory address under a different name:
EditX CmdX BSS 2 ; reserve two bytes for EditorX and Command Line X coordinatesSimple as that. Obviously, this takes no extra code space, and you get the added benefit of being able to refer to a memory location in it's proper context at the appropriate points in your code.
#45 OFFLINE
sometimes99er
-
-
- 2,307 posts
River Patroller
- Location:Denmark
Posted Sat Oct 9, 2010 1:50 AM
retroclouds, on Wed Aug 18, 2010 2:06 AM, said:
sometimes99er, on Tue Aug 17, 2010 2:43 PM, said:
How about dropping the VDP shadow registers and functions, and simply supply a good bunch of equates ? Wouldn't it save a few bytes both in RAM and ROM ?
Considering that we only have 256 bytes to play with, I'd say being able to save 8 bytes is a lot.
And I won't mention more than one sound source anymore - I guess it could potentially destroy your beauty sleep.
#46 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Sun Oct 10, 2010 11:47 AM
If the game developer decides not to use a stack, then he can use the stack pointer(R9) as temporary register TMP5.
At this time I only have 1 remaining spectra2 routine that makes use of the stack, and it can easily be rewritten.
I've almost finished doing all required modifications to the thread scheduler. I'm quite pleased with it so far.
Next up are (in no particular order): speech synthesizer, bank-switching & utility, random.
I now have a pretty good picture of what will be part of the spectra2 release.
It means I can start working on the documentation soon.
At this time I only have 1 remaining spectra2 routine that makes use of the stack, and it can easily be rewritten.
I've almost finished doing all required modifications to the thread scheduler. I'm quite pleased with it so far.
Next up are (in no particular order): speech synthesizer, bank-switching & utility, random.
I now have a pretty good picture of what will be part of the spectra2 release.
It means I can start working on the documentation soon.
#47 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Sun Oct 17, 2010 1:10 PM
Hurra! Todays' a good day! I've got the speech synthesizer code up and running in spectra2! It's great to hear Mark's voice while multiple threads are running (without using memory expansion).
I didn't have time to play with QBOX yet, so I tried the LPC data at http://www.planet-99.net/wotw.htm
I didn't have time to play with QBOX yet, so I tried the LPC data at http://www.planet-99.net/wotw.htm
#48 OFFLINE
Willsy
-
-
- 1,220 posts
Stargunner
- Location:Uzbekistan (no, really!)
Posted Mon Oct 18, 2010 7:26 AM
Excellent! Did you do also implement speaking words from the synths built in ROM? That takes a bit more work...
That's the one I am going to work on first, as it's the harder of the two. Well, it's not that it's harder - just more to it, that's all!
That's the one I am going to work on first, as it's the harder of the two. Well, it's not that it's harder - just more to it, that's all!
#49 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Mon Oct 18, 2010 11:42 PM
Willsy, on Mon Oct 18, 2010 7:26 AM, said:
Excellent! Did you do also implement speaking words from the synths built in ROM? That takes a bit more work...
That's the one I am going to work on first, as it's the harder of the two. Well, it's not that it's harder - just more to it, that's all!
That's the one I am going to work on first, as it's the harder of the two. Well, it's not that it's harder - just more to it, that's all!
Didn't work on that yet. Speaking words from the built-in ROM is definetely on my list for the first release though. I really want to have that available.
The thing is that I need to work on sound & speech development at home. I don't wanna bother people
with garbled speech or crashing sounds at work (lunch break) or in the train
Most likely I'll be doing work on some small utility functions first
#50 OFFLINE
retroclouds
-
-
- 1,257 posts
Stargunner
- Location:Germany
Posted Sat Oct 23, 2010 12:36 PM
Here's a little speech demo I did. I recorded my own voice using Audacity and then followed Marks' instructions to generate the required LPC data with QBOX.
Didn't spend too much time on it and it sounds rather rough
Then spectra2 was used for playing the speech sample.
Here's the ROM image for classic99 and MESS.
Again this comes without warranties.
It was tested on classic99 and on a real TI-99/4A with speech synth.
hw.zip 5.94K
14 downloads
Didn't spend too much time on it and it sounds rather rough
Then spectra2 was used for playing the speech sample.
Spoiler
Here's the ROM image for classic99 and MESS.
Again this comes without warranties.
It was tested on classic99 and on a real TI-99/4A with speech synth.
hw.zip 5.94K
14 downloads
0 user(s) are browsing this forum
0 members, 0 guests, 0 anonymous users
Like us on Facebook
Follow us on Twitter
Watch us on YouTube