Jump to content

retroclouds

+AtariAge Subscriber
  • Posts

    2,499
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by retroclouds

  1. scratch-pad memory usage (update 2) Well, this isn't really a big update. Just updating the documentation. Guess that the memory layout pretty much has stabilized. At least for a basic installation. By that I mean that each game or program using spectra2 must use the range >8300 - >8331 as described. I call this range "memory area 1". There might be a small "memory area 2" in the future. This setting will be controlled by one of the flags in (D). Reason for that is that some of the routines may require some additional pointers for doing some stuff. However this area will be optional and depends on the features you use. I'm trying to get some modular structure in place without bloating memory if the feature's aren't switched on. We'll see, these are just all ideas for now 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) Mini-os status flags These flags will be used for controlling various features of the library. This is what I have in mind: * Bit Description * =================================================================== * 15 Sound player tune source 1=ROM/RAM 0=VDP MEMORY * 14 free * 13 free * 12 Keyboard mode 1=real 0=virtual * 11 free * 10 Timer has hyperthread 1=yes 0=no * 09 free * 08 free * 07 free * 06 free * 05 free * 04 free * 03 free * 02 Speech synth present 1=yes 0=no * 01 VDP PAL version 1=yes 0=no * 00 32K memory expansion 1=yes 0=no E) 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.
  2. Thanks for sharing. Can you tell me what is used for generating the speech in the demo ?
  3. 100 fonts, now how cool is that Just wondering, are there more cool textmode fonts out there. Do you remember "nibbler" ? it's a sector copy program for copying disks on the TI-99/4A. If I'm not mistaking that one ran in text mode. Always liked the font they used.
  4. I'd say the Atari controller adapters appear quite often on ebay. So they shouldn't be hard to find. FYI: There's currently a gamepad in development for the TI-99/4A. The gamepad will not require the atari adapter. You can read all about it here. That will be very cool; also for the new games currently in development.
  5. OLD DSK1.RFK oh, don't forget that you might have to do a "CALL MOUNT(1,1)" first. The format is: "CALL MOUNT(drivenum,volnum)" drivenum = 1 .. 3 volnum = 1 .. x Where x is the maximum number of disk images on your compact flash card. Note: be sure to checkout TI-99DIR. It's a great tool for preparing/filling your compact flash card.
  6. Not stupid at all.... There are times you may wish to enable interrupts to allow a peripheral card to be serviced by the ISR, such as the RS232 input ring buffer. I believe this is what you are seeing and referring to in the interrupt routine. But for file and most other DSR control, no, interrupts need not be enabled. The DSR routines usually do not enable interrupts either, to avoid conflict conditions between cards and problems with setting the VDP addresses. Thanks for pointing that out. That is good news
  7. Grab them while you can, Jaime has some for sale right now. It's the version with the RS232. He still has 3 left. Check out ebay article eBay Auction -- Item Number: 200511000666
  8. register usage So let's talk registers now. Below you find the overview on how the registers will be used in spectra2. !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 Virtual game keyboard flags or keycode R13 H Copy of VDP status byte and internal counter for sound player R14 I YX coordinates of cursor R15 J VDP write address ============================================================================= A) General purpose registers (R0-R3) You can use these registers in your subroutines, but if you change any of these registers you'll have to push them on the stack first. Ofcourse upon subroutine exit you'll have to pop the old values of the stack. There are subroutines to help you with that. If your subroutine is called as a timer, then R0-R2 will contain information that identifies the slot, target tick count, etc. Hence the requirement for pushing/popping if you change R0-R2. Also R0-R3 are the registers to use if you are going to implement nested subroutines. B) Temporary registers (R4-R7) Use these registers as you please. They are considered temporary and they can (and will) be overwritten if you call any of the built-in functions. Nonetheless, most of the time you are safe to use R4-R7 in favour of the (A) registers. It'll save you the need to push & pop. 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) Virtual game keyboard flags (R12) 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 in R12. 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) Current Y and X position (R14) 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. 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.
  9. Well, the sound system I have in there is still very primitive to say the least. That could also have to do with the fact that my music/sound skills are like zero, so perhaps I have neglected that area a bit I'll for sure consider it. For now I'm happy I'm kinda compatible with the ISR sound routine. Yeah, that makes you wanna take a closer look at the Colecovision BIOS. The sound player they have in there really kicks a****
  10. Sure wished I could join you guys, but that won't be possible. The way it looks I won't be attending any of the meetings this year. Notthingham is out of the picture as well.
  11. This might be a stupid question, but must interrupts be enabled for file access to work ? Looking at TI Intern I found a section of code in the interrupt routine that checks DSR roms. So I suppose interrupts must be enabled ? Right ?
  12. scratch-pad memory usage (update 1) ok, I have a major update on scratch-pad memory usage people I've been tinkering with the register usage and I removed the VDP shadow register feature. Due to this scratch-pad memory requirement has dropped from 65 bytes to 50 bytes. That means we're now using 19.5% instead of 25% of the available scratch-pad memory. Here are the updates: Address Description Size (bytes) ======= ================================= ============ >8300 A Register Workspace 32 >8320 G Address of timer table 2 >8322 J Address of sound table 2 >8324 L Mini-os status flags 2 >8326 M Loop code + return from stack 12 ================================================================== Total bytes 50 A) Register workspace That's obvious right? On the TMS9900 CPU we need a workspace in memory to hold the 16 registers. B) VDP shadow registers Dropped this feature. We should be able to manage without it. (8 bytes saved) C) Columns per row Dropped this feature. We'll definitely manage without it. (1 byte saved) E and F) Current Y and X position We'll use a general purpose register. (2 bytes saved) G) 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. H) Highest slot in use and I) Internal counter for timers We'll use a general purpose register. (2 bytes saved) J) 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 (L). K) Virtual game keyboard flags We'll use a general purpose register. (2 bytes saved) L) Mini-os status flags I've decided to use 2 bytes instead of 1 byte for the status flags. (1 byte lost) M) 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. You'll notice that I moved quite a few values into the general purpose registers. Considering we have 16 registers in 1 workspace to our disposal, we might as well use them. I'll be going into the details on register usage soon
  13. Sure hope we can keep A.A. that way; a clean and safe place I've been staying pretty low at the Y! group lately, because there is just way too much drama for me. Also too much off topic stuff. Dunno, somehow I get the feeling that each time A.A. is mentioned it seems to be a bad thing. Jeez, it's not like we want to split the TI community or something. We just wanna rock and get new cool TI-99/4A software & hardware out there
  14. wow, I had forgotten all about the version with the cracks. I haven't seen that in years... decades maybe... I feel old now. - Ahem... I was under the impression that this was a young mans group. If your over 30 perhaps you would feel more comfortable with the geriatrics over on the Yahoo (with the dash) group .... Thank god I'm still only 27 (or so....)
  15. As usual a very clear explanation Matthew!
  16. I've added a wiki page on ninerpedia for keeping track of the spectra2 documentation. Ofcourse this Atariage thread will remain the main thread for sharing and discussing further developments. But it's kinda difficult keeping a changing documentation in a forum format, that's why I chose the wiki format: It allows others to join and make corrections and enhancements. From time to time I'll collect the changes in the forum posts and update the wiki accordingly. You can check it out here. Still learning how to format a wiki, so bare with me people
  17. Thanks for sharing this Daniel. That's very cool Just wondering, is there a special reason why the tniASM cross assembler is used? Or will other Z80 assemblers work as well, e.g. the MSX sjam assembler ?
  18. wow, you sure keep 'em coming
  19. thanks I hope to finish the scratch-pad memory setup soon. Once that is done I'll be able to "convert" my Tutankham source code for using the SPECTRA2 calls.
  20. If that's the case, I could imagine you have some spanish MSX folks watching your channel Seem to recall that quite a few MSX DEV titles were developed by spanish teams.
  21. Thanks. Yes, it would save 8 bytes in RAM. On the other hand I could lose some of the flexibility for the subroutines I have in mind. Considering that we only have 256 bytes to play with, I'd say being able to save 8 bytes is a lot. Thinking about this more I could reclaim a lot of the flexibility I had in mind by clever register usage. I've already decided that I'll drop the columns per row value. It saves 1 byte and a few bits in the mini-os status byte So, this means I could save 9 bytes in total. That doesn't mean the mini-os memory usage will be 9 bytes less. What I didn't talk about yesterday is that I'll need 1 more byte for the sound player. I also don't know if I'll need 1 additional byte for a random seed. I know we had a thread about this on Atariage just a while ago. I'll have to do some research on that topic. I've also been thinking on using some of the "monitor" & GPL routines that are in the 99/4A system roms. In that case I'll have to make my memory layout "compatible". That certainly looks like a challenge. Did you know, that there is a coincidence check routine burried in the system rom that allows you to do coincidence detection between sprites/sprites, sprite/tiles, tiles/tiles. Implementing a coincidence detection routine would take quite some ROM space. That is why I'm looking in using this one. More to follow..... On a sidenote: Writing and sharing ideas on spectra2 really helps me focus on what is important
  22. scratch-pad memory usage I've been thinking a lot about this library lately and what I would like it to become. I see SPECTRA2 more as a miniature operating system for running games. It will help the processing of input (joystick, keyboard) and output (video, sound and speech). A core concept is the use of timers for running multiple tasks. Ofcourse it will also include some utility functions that help in the communication with the VDP, setting up timers etc. Therefore I have decided that I won't be including many super duper high-level VDP tricks in the library. Why? Because I think such high-level routines put a lot of restrictions on the programmer. What I like about assembly language is that -as a programmer- you have full control. So I don't want SPECTRA2 to put too many constraints on the programmer. Instead it should offer a basic structure, help master basic functions and leave the game programmer the freedom to do what he needs to do, concentrate on the game The main focus is that it should support games that run from the cartridge space on a bare TI-99/4A console. In that case we only have 256 bytes of CPU RAM (scratch-pad memory) to our disposal. If you think about it as a mini-os, then it's clear it also needs some memory for its own. I've set the limit (including register workspace) to be 64 bytes. That is 25% of the available memory. Is that a good value? I don't know, so let's go through the details. Address Description Size (bytes) ======= ================================= ============ >3200 A Register Workspace 32 >8320 B VDP shadow registers 8 >8328 C Columns per row 1 >8329 D Copy of VDP status byte 1 >832A E Current Y position 1 >832B F Current X position 1 >832C G Address of timer table 2 >832E H Highest slot in use 1 >832F I Internal counter for timers 1 >8330 J Address of sound table 2 >8332 K Virtual game keyboard flags 2 >8334 L Mini-os status flags 1 >8835 M Loop code + return from stack 12 ================================================================== Total bytes 65 Wait a minute, that's 65 bytes instead of 64! True, so we'll have to squeeze out 1 more byte. Highest candidate on the list for now is [C]. Considering that about 99% of the games I know run in 32 columns per row, this is perhaps a value we can get rid of. But let's go through each of the items first. A) Register workspace That's obvious right? On the TMS9900 CPU we need a workspace in memory to hold the 16 registers. B) VDP shadow registers The VDP registers are write-only. Therefore, we keep a copy in memory so we can easily set some of the registers or set certain bits and then dump them to the VDP all at once. Or one at a time as you require it. This concept is not new. It was already there in SPECTRA but I have now reduced required memory from 16 bytes to 8 bytes. C) Columns per row Depends on the video mode (32, 40 or 64). This value can help in calculating the VDP offset based on row and column information. If this needs to go, it could be replaced with one of the flags in (L) or just assume we only write games in 32 column mode. E and F) Current Y and X position This is new in spectra2. We'll have some functions you can use to put tiles at specific coordinates without you having to calculate each individual position. G) 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. H) Highest slot in use Keeps track of the highest slot used in the timer table. Was already present in SPECTRA. Size is now 1 byte instead of 2 bytes. That still allows 256 slots, so more than enough if you ask me :-) I) Internal counter for timers Already had that in SPECTRA. Size is now 1 byte instead of 2 bytes. J) 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 (L). K) Virtual game keyboard flags Already had the concept of a virtual game keyboard in SPECTRA. The idea is that we have a keyboard (including mapping to joysticks) and each bit represents a game key. This is ok for arcade games where you only use a few keys (plus redo/back). Dunno if it will be enough for other types of games though. As any game depends on input I think it's ok to sacrifice 2 bytes. L) Mini-os status flags New. These status flags keep track of the environment SPECTRA2 is running in. Below are the flags(bits) I can think of right now. Dunno if 1 byte will be sufficient in the future though. Sound table is in VDP memory Speech synthesizer present 32K RAM expansion present NTSC/PAL console 40 columns mode 64 columns mode M) 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. Here's the code that is copied on startup. I'll be going into detail once I covered spectra2 register usage. Perhaps we can squeeze out some more bytes here. What I can say is that -among others- the tight loop is used for reading/writing to the VDP. The "return from stack" code is there for speed reasons and because I want to implement some kind of routine for calling subroutines accross 8K banks. By fiddling with the "return from stack" code, subroutines could become bank-aware. * ; Tight loop DATA >0000 ; \ M3LOOP: opcode+operands set by caller DATA >0606 ; | DEC R6 (TMP2) DATA >16FD ; / JNE M3LOOP DATA >045B ; / B *R11 * ; Return from stack DATA >C2FD ; \ M3POPR: MOV *RSTACK+,R11 DATA >045B ; / B *R11 This is still a work-in-progress, but I think we've got the basic scratch-pad memory structure going. I still have a lot of questions at this time. For one I want to be able to call "MONITOR" and GPL functions. Not sure if we're on the safe with the current setup. In fact, we haven't talked about register and stack-usage yet. That will be for one of the next posts
  23. How about if you put a wave sprite in front of the ship ? You could move the ship very slowly, like every 3 seconds and perhaps 4 or 8 pixels at once together with the wave sprite. As long as you don't use the automatic sprite motion (ISR) both sprites could be aligned. Edit: I love the game title "Calimari Carl"
  24. Hi there! Good to have you back, we've been missing you here.
  25. Hi AA737! First of all, welcome to our Atariage group. You'll probably find a lot of interesting stuff here You also might want to check out the top thread (Development Resources sticky thread) as it has a reference to the TI-FAQ on Ninerpedia. Now to your question: His ebay seller name is schmutzig1952. Just recently he had a CF7+ with serial connection up for sale. It went in a split second. Apparently he is working on a new batch of those. Note that the device now is called "nanoPEB" instead of CF7+. Look at ebay article 200505522099 for some pictures. Good luck!
×
×
  • Create New...