TI-99/4A with a Pipistrello FPGA board

[Tursi]

That's correct. PROGRAM image files, which are handled only by LOAD and SAVE opcodes, are the analog of a 'raw' file. They just function as blocks of data. But the record-based files are the standard, and it's important because the system is sector based -- and a record never crosses a sector boundary. This means that every block of 256 bytes contains only as many records as cleanly fit. Fixed size records are just stored, and variable size records have a length byte before each record. (Which is why Fixed 128 is used as a default filetype for foreign files -- on the disk they end up looking exactly like the source file because two records fit exactly).

 

But, that makes PROGRAM LOAD a great first step, because it's arguably the easiest disk operation to implement. You can immediately test with it, too, since many games are distributed in this format.

[speccery]

But, that makes PROGRAM LOAD a great first step, because it's arguably the easiest disk operation to implement. You can immediately test with it, too, since many games are distributed in this format.

 

 

Excellent and thanks again for all the information!

One quick stupid question: for the default fixed 128 filetype (or for all fixed record files for that matter) I suppose the length is stored only once? I'm sure that will become clear by reading the documentation, but thought I'll ask anyway

[Asmusr]

 

 

Excellent and thanks again for all the information!

One quick stupid question: for the default fixed 128 filetype (or for all fixed record files for that matter) I suppose the length is stored only once? I'm sure that will become clear by reading the documentation, but thought I'll ask anyway

 

Yes it's stored once. For disk files that's in the file descriptor record. You can specify it again in the PAB when you open a file, but I believe if you set the record length to 0 in the PAB the DSR would use the record length recorded with the file (?). For variable records on disk the record length is specified in the first byte of the record. A record length of 255 is used as an EOF marker.

[Tursi]

Excellent and thanks again for all the information!

One quick stupid question: for the default fixed 128 filetype (or for all fixed record files for that matter) I suppose the length is stored only once? I'm sure that will become clear by reading the documentation, but thought I'll ask anyway

I should note too that the Fixed128 that I mentioned is a /convention/ used for foreign files (being files with no header at all). It's definitely not a part of the TI Disk Controller (which obviously can't read foreign files, since to be stored on the disk it must by definition have the type information in the directory ).

 

Fixed format files contain the length of the record ONLY in the metadata. Records are simply packed into each sector, as many as will fit.

 

Variable format files, as noted by Asmusr, have a single byte length before each record. The metadata indicates the maximum record length. Although the length of >FF indicates the end of a /sector/, not necessarily the file. (Necessary since only the writer knows if the next record will fit ).

 

End of file is indicated by the metadata, which specifies how many sectors there are and the offset in the last sector. Rather than go by memory I'd say check my code, there were some gotchas in dealing with it IIRC.

 

As for opening with a record length of 0, the behavior is device-dependent, but the TI controller will assign the record length.

 

The biggest issue I had with reading records was making sure the PAB was updated correctly after a read - you have to change it and return the data back to the TI. There was some unexpected subtlety regarding what to update when, and differences between fixed and variable length files. There should be ample notes in the code, hopefully.

[Asmusr]

Although the length of >FF indicates the end of a /sector/, not necessarily the file. (Necessary since only the writer knows if the next record will fit ).

 

[speccery]

End of file is indicated by the metadata, which specifies how many sectors there are and the offset in the last sector. Rather than go by memory I'd say check my code, there were some gotchas in dealing with it IIRC.

Thanks I will definitely check your code! I did a quick glance over the code the other evening, mainly to get an overview. It seems there is a subtleties to deal with.

 

The good news is that I have gotten saving to work now (with the TMS99105 system)! I am not putting in the TIFILES header yet, but I can save TI Basic programs on the disk of the PC. So I could write "save DSK1.HELLO" and the program arrived seemingly safely on the disk of the PC.

 

Need to add loading next

 

This by the way marks the first time I have been able to write something to disk on an actual TI - well on my clone - but close enough! Once I have enough functionality here I will port the code over to the Pipistrello memory expansion, to actually run this on a TI.

Edited November 11, 2016 by speccery

[speccery]

Got loading working too!

I am now running RXB 2012 program COINC happily on the TMS99105 system . I had to add "support" for DSR operation OPEN file command in the sense that it always returns an error, otherwise RXB gets stuck in the beginning as it wants to open DSKx.LOAD and my DSR hands the OPEN request to the PC and waits for PC to return, and my PC side program just didn't do what to do with it.

 

I suppose I need to find next some programs to load from somewhere, to test things more.

 

I did find a bug in the hardware sprite handler: the vertical sprite coordinate >D0 means that there are no more sprites, and the hardware should stop there... except in my case my sprite generator starts from the bottom sprite #31, working it's way to sprite zero. I did it that way since sprite 31 has the lowest priority and is overdrawn by all the other sprites. My implementation does stop when it finds >D0, but that is useless since sprite scanning has to start from zero. Regular TI Basic puts >D0 at address >300, meaning there are no sprites. Since I start from the end, random sprites appear on the screen as I type basic code and the VDP memory area >300..>37F is used by TI Basic. It seems TI Basic uses some of the memory in that region for input buffers or something like that.

 

So I suppose I need to modify the hardware to have an extra counting step, which should count the number of active sprites starting from sprite zero, and stopping at sprite 31 or at vertical coordinate >D0. From there it could draw sprites as before, from highest numbered sprite to lowest numbered one.

[Tursi]

That's pretty awesome! And if you post a vid, I bet Rich would love to see RXB running on your clone!

[speccery]

Sure, I'll try to find time this weekend to make a clip.

 

I need to do something with the keyboard repeat rate, the faster CPU clock speed makes typing hard. Luckily I have a great mechanical keyboard which allows short keypresses, so typing is not impossible. One way to do this would be to remove repeat function altogether, although that would suck too.

[speccery]

I have a couple of questions. I posted these both here and on the RXB thread. Help would be appreciated. I hope my questions are not moronic, question 2 especially...

 

Background: I think I have successfully now added 256K SAMS memory extension to my TMS99105+FPGA system. I am right now debugging it.

 

Questions:

1) RXB2015 detects SAMS, but it claims 1024K are available, although I have only 256K. I wonder how the detection works? Maybe it is bad behaviour, but in my system memory wraps around, i.e. the 256K of expanded RAM I have appears four times in the 1024K SAMS memory map. Would it be better behaviour to just respond with zeros or something above 256K instead of wrapping around?

 

2) How much memory does "IN THE DARK" require? I don't exactly know what this things is, I am hoping it is a game . In addition to working with SAMS I am working with disk support, and it partially works (yippee! but it is save & load only, i.e. PAB opcodes 5 and 6). When I am loading the game the last file it loads is DSK1.ITDT16, then it gets stuck.

 

3) There was a SAMS memory test program somewhere, I think it was in the extended basic suite cartridge. On the TMS99105 system I don't have enough memory configured to load that 512K of cartridge ROM and 128K of GROM simultaneously (the FPGA board has one megabyte of memory, but I am currently only using half of it, the other half is on the upper half of the FPGA board's 32-bit memory bus which I am not yet supporting).

Is this SAMS test program available somewhere as a stand-alone cartridge image?

[Asmusr]

I have a couple of questions. I posted these both here and on the RXB thread. Help would be appreciated. I hope my questions are not moronic, question 2 especially...

 

Background: I think I have successfully now added 256K SAMS memory extension to my TMS99105+FPGA system. I am right now debugging it.

 

Questions:

1) RXB2015 detects SAMS, but it claims 1024K are available, although I have only 256K. I wonder how the detection works? Maybe it is bad behaviour, but in my system memory wraps around, i.e. the 256K of expanded RAM I have appears four times in the 1024K SAMS memory map. Would it be better behaviour to just respond with zeros or something above 256K instead of wrapping around?

 

2) How much memory does "IN THE DARK" require? I don't exactly know what this things is, I am hoping it is a game . In addition to working with SAMS I am working with disk support, and it partially works (yippee! but it is save & load only, i.e. PAB opcodes 5 and 6). When I am loading the game the last file it loads is DSK1.ITDT16, then it gets stuck.

 

3) There was a SAMS memory test program somewhere, I think it was in the extended basic suite cartridge. On the TMS99105 system I don't have enough memory configured to load that 512K of cartridge ROM and 128K of GROM simultaneously (the FPGA board has one megabyte of memory, but I am currently only using half of it, the other half is on the upper half of the FPGA board's 32-bit memory bus which I am not yet supporting).

Is this SAMS test program available somewhere as a stand-alone cartridge image?

 

Re 3: http://atariage.com/forums/topic/253095-flashrom-99-image-repository-9062016/?p=3592592

[speccery]

After taking a look I can reply to question 2 myself - I ran this under classic99 and the highest numbered page was >65 i.e. 101 decimal, so I would be able to run this if I enabled 512K of expanded memory.

 

Except that alone is not enough, before I support also OPEN/CLOSE/READ operations too, since the game (yes I noticed it is a game ) wants to load some machine code too. Thus more work ahead before I can enjoy this.

 

To elaborate, the FPGA board has 1M of static RAM (plus 64K on chip FPGA RAM, which I want to save for hardware use, my VDP implementation uses 18K of this memory). For something like RXB I need to load console ROM (8K), console GROM (24K), my own DSR (8K), RXB ROM 16K, RXB GROM 40K for a grand total of 96K - that's a respectable amount of code. Even if the hardware memory mapping was optimally done, that means that with this FPGA board I am never going to have 1M of SAMS and all the ROM code fitting into 1M. In practice probably the best I could do would be something like 768K for SAMS, but I assume that is not a standard amount of paged memory, so probably something like 512K would be the practical maximum.

[+Ksarul]

The SW99ers SAMS board works as either 512K or 1024K, so limiting yourself to 512K is no problem at all, generally.

[speccery]

 

Re 3: http://atariage.com/forums/topic/253095-flashrom-99-image-repository-9062016/?p=3592592

 

 

Thanks - I need to try this out.

[speccery]

The SW99ers SAMS board works as either 512K or 1024K, so limiting yourself to 512K is no problem at all, generally.

 

That's great to know, thank you!

[Tursi]

I need to do something with the keyboard repeat rate, the faster CPU clock speed makes typing hard. Luckily I have a great mechanical keyboard which allows short keypresses, so typing is not impossible. One way to do this would be to remove repeat function altogether, although that would suck too.

Classic99 has a hack to slow down the keyboard when the CPU is sped up (which involves watching the PC and hacking values into RAM directly), but it's not something that would work well in hardware. BUT, maybe you can just increase the key repeat delay, and/or the debounce time, which are both in the KSCAN function. If you don't already have TI INTERN, it's got a great commented disassembly of the TI ROM and GROMs. Can grab it here: http://www.99er.net/download2/index.php?act=view&id=102

[Asmusr]

I'm having the same issue with RXB 2015 in my emulator js99er.net: No matter what AMS size I emulate RXB still reports 1024K. I'm also wrapping around so a register set to 128 will cause the same RAM to be accessed as a register set to 0 when emulating 512K. I have a real 128K AMS card but unfortunately not a real RXB cart to test this with.

[+Lee Stewart]

My fbForth 2.0 and @Willsy’s TurboForth (from whence I extracted the ALC) both assume 1024KiB SAMS when it is used. I would need to revisit that code to manage other amounts of SAMS memory.

 

...lee

[speccery]

I posted updated files to GitHub and wrote an update of the project at Hack a day

 

There is a slew of updates. Saving and loading seems to work a bit, and I was pleasantly surprised in that adding that support also enabled editor/assembler cartridge option 5, so I can load now machine code programs "the TI way" instead of directly injecting that using the PC memory access mechanism.

 

I've been testing with AMSTEST4, but something funny is going on and the test does not pass. Actually even the screen it draws doesn't come up right. It is possible the FPGA synthesis version I'm using currently is not a good one, but most likely I just have an old fashioned bug, timing or otherwise.

[speccery]

I'm having the same issue with RXB 2015 in my emulator js99er.net: No matter what AMS size I emulate RXB still reports 1024K. I'm also wrapping around so a register set to 128 will cause the same RAM to be accessed as a register set to 0 when emulating 512K. I have a real 128K AMS card but unfortunately not a real RXB cart to test this with.

 

That's nice to know, at least the behaviour I am seeing is consistent to your findings. Maybe RXB just assumes that AMS means 1024K. Thank you for checking!

[speccery]

Update at hack-a-day. I copy here what I wrote there, but the pictures are currently only at hack-a-day:

 

Sometimes I just feel stupid:

I had added support for 256K of SAMS compatible memory extension (SAMS was a memory expansion standard for the TI-99/4A) largely using VHDL from my earlier FPGA project, but the memory test program just would not work (AMSTEST4). The scary part was that once I ran that program, the screen just went weird. The colours were bogus, and there was some misalignment on the text that was written. Basically it all seemed wrong, I was doubting FPGA routing and timing issues.

I did not have time to work on this and during that time I realised, that AMSTEST4 was the very first program I run on my TMS99105 system to use 40 column mode. My video processor implementation of the TMS9918 does not support that. But instead of completely not working, it displays the text in 32 column mode, which made everything look funny. I got to work.

I was again surprised how little effort it took to add support for 40 column mode. There effectively are only three changes in the VHDL code:

• The colours need to read from VDP register 7 foreground (bits 7..4) and background (3..0) instead of reading them from VRAM. The fix was easy - ignore the contents of VRAM read for colors in text mode and override with register contents.
• The character cells are 6 pixels wide. It was super easy to fix this - I just initialised my character pixel counter to a starting value of 2 instead of zero in text mode. Voila - now character cells are narrow.
• Finally, the line length is 40 columns, not 32, so the hardware needs to compare against 39 instead of 31 in text mode.

That was all there was to it. Below is a picture of it working (incidentally showing that SAMS memory test passes now too, more about that after the picture):

So there it is in all its 40 column glory. If you wonder about the blue bar on the right - that's there due to left over data in the line buffer. The previous picture is basically the boot up screen below (well there is a menu in between but same stuff). The previous pictures are in 32 column mode, and 32 times 8 is 256 pixels i.e. the full TMS9918 width, but going to 40 column mode means 40*6 equalling 240 pixels, so there are 16 fewer pixels. Since the 40 column mode does not update the line buffer (used for VGA scan doubling and sprites), the previous contents are there. In text mode the hardware should turn on horizontal blanking for those last 16 pixels, but at least the picture shows the quirk and proves we have the FPGA at work.

Speaking of 16-pixels, I also added a 16 pixel offset vertically, to be able to see the topmost line well. This offset was much harder to add than the text mode: it took several attempts, while text mode worked right the very first time.

The final problem I had earlier, the SAMS memory test not working, was something really stupid: the memory paging actually worked already, but the test application seems to check the lower bytes of page number registers too. The SAMS extension to my understanding assumes that page numbers are stored in every other byte from address >4000 onwards: >4002, >4004, >4006 up to >400E. This was done due to the 16-bit nature of the TI-99/4A, even if the individual page registers are only 8-bits wide. As the external bus of the TI-99/4A was 8 bits wide and it could not do byte proper byte addressing, the registers were spaced out so that only every other byte was used. Even addresses are the ones where software should write page values, and reading from them yields the same values again, but the odd values could be ignored. That's what I thought, but the test program needs the hardware to replicate (during reads) the register values in the odd address too - the same behaviour as with the original TI-99/4A. Fair enough, and now it works.

Edited November 15, 2016 by speccery

[Willsy]

<pedantry>

AMS: 256k

SAMS: 1024k

</pedantry>

:-)

[speccery]

<pedantry>

AMS: 256k

SAMS: 1024k

</pedantry>

:-)

well I am on my way to 512K, just ran out of hobby time, I could maybe even do 768K on this board - but I am not sure if 768k is a thing

[+jedimatt42]

<pedantry>

AMS: 256k

SAMS: 1024k

</pedantry>

:-)

I have an AMS board from yesteryear, that support 512k. Just to confuse things...

 

I have to take that back... it can be 128k, upgraded to 256k. Still confuses things.

 

-M@

[Willsy]

The final problem I had earlier, the SAMS memory test not working, was something really stupid: the memory paging actually worked already, but the test application seems to check the lower bytes of page number registers too. The SAMS extension to my understanding assumes that page numbers are stored in every other byte from address >4000 onwards: >4002, >4004, >4006 up to >400E. This was done due to the 16-bit nature of the TI-99/4A, even if the individual page registers are only 8-bits wide. As the external bus of the TI-99/4A was 8 bits wide and it could not do byte proper byte addressing, the registers were spaced out so that only every other byte was used. Even addresses are the ones where software should write page values, and reading from them yields the same values again, but the odd values could be ignored. That's what I thought, but the test program needs the hardware to replicate (during reads) the register values in the odd address too - the same behaviour as with the original TI-99/4A. Fair enough, and now it works.

 

That's good. That means TurboForth and fbForth should work on your system with the SAMS memory.

; initialise SAMS card if fitted
li r12,>1e00 ; sams CRU base
sbo 0 ; enable access to mapper registers
sbz 1 ; disable mapping while we set it up
li r0,>4004 ; register for >2000
li r1,>f8f8 ; map bank >f8 into >2000
mov r1,*r0+ ; do it
li r1,>f9f9 ; map bank >f9...
mov r1,*r0+ ; ...into >3000
; now set up the banks for high memory...
li r0,>4014 ; register address
li r1,>fafa ; register value
li r2,6 ; loop count
sams mov r1,*r0+ ; write to the register
ai r1,>0101 ; next register value
dec r2 ; finished?
jne sams ; loop if not
sbo 1 ; enable mapping
sbz 0 ; lock the mapper registers

See http://turboforth.net/source/Bank1/1-16-Initialise.html

Edited November 15, 2016 by Willsy