Jump to content

ralphb

Members
  • Content Count

    671
  • Joined

  • Last visited

  • Days Won

    1

ralphb last won the day on May 2 2017

ralphb had the most liked content!

Community Reputation

867 Excellent

About ralphb

  • Rank
    Dragonstomper

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    Developers, developers, developers, developers

Recent Profile Visitors

7,620 profile views
  1. There is one multi-cart for the Pyuuta I know of, but sadly no FinalGROM or Ubergrom. This means that you probably need to use a programmer to flash your assembled program to an EEPROM on an adapter cartridge. There are probably additional constraints, similar to the GPL header of TI 99, that you would need to include in your program. Maybe someone else has any additional insights.
  2. ralphb

    SDD 99

    A while ago I decided to skip a second prototype video and go straight for the (semi-)final PCB ... which isn't to say that it'll be ready this year. The MCU variant I'm currently using is actually somewhat rare, so it'll be safer to switch to another variant or go BGA. But Klaus is right, I'll present the current status at Leicester.
  3. Fair enough. Attached is the source code, and the disk image with the file OVERRIDE to read, and the E/A#3 file PUB to read it. In the top left-hand corner you see the status, in the right-hand corner you may see E for error and L for zero-length result. Right now you see L for reading the second record. The file OVERRIDE was created in BASIC. It's probably something really simple, but I'm currently stumped. w.dsk pub.asm
  4. I changed the code so that it would just update byte 0 and byte 5 in the PAB, instead of overwriting the entire PAB, and made it use the E/A DSRLNK -- but no change. Looking at the data sector of file OVERRIDE, everything looks fine. But the FDR shows only one level 3 record at bytes >12->13, instead of two! arcturus ~/ti99 > xdm w.dsk -S ">3" 00: 4F 56 45 52 52 49 44 45 20 20 00 00 80 06 00 01 OVER RIDE .. .... 10: 41 28 01 00 00 00 00 00 00 00 00 00 33 00 00 00 A(.. .... .... 3... 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .... .... .... .... ... F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .... .... .... ....
  5. Argh, this is actually quite funny. First of all, to detect the "not reading anything" case, I invalided the buffer before each read -- but I invalided the RAM buffer, not the VDP buffer. Fixing that, I saw exactly what you suggested. Then I was checking for errors, but for simplicity I only checked for error code 1-7. And you guessed it, it was error 0 for the second read. Also, about byte 5 containing the number of bytes to read. Originally, I put zero there. Theirry describes it this way, whereas the E/A manual is ambiguous. But when I ran that, I noticed that the length of the results for read 2 and 3 actually depend on the number I put there, so I thought you're supposed to supply that number. In hindsight, it was just I myself that provided the result length, since the DSR didn't really run at all. The PABs now look like this: pab_open_read: data >0014, pab_buf, >2800, >0000, >000d text 'DSK1.OVERRIDE' pab_read1: data >0214, pab_buf, >2800, >0000, >000d text 'DSK1.OVERRIDE' pab_read2: data >0214, pab_buf, >2800, >0000, >000d text 'DSK1.OVERRIDE' Why would read 2 throw an error? EDIT: Oops, forgot about byte 1, but setting it to zero didn't change anything.
  6. Thanks, but changing all record numbers to 0 didn't change the result. This is so strange, because I remember I succeeded in the past. I must be doing something simple wrong.
  7. Consider these PABs for reading a DIS/VAR 40 file with the TI floppy controller: pab_open_read: data >0014, pab_buf, >2800, >0000, >000d text 'DSK1.OVERRIDE' pab_read1: data >0214, pab_buf, >2828, >0000, >000d text 'DSK1.OVERRIDE' pab_read2: data >0214, pab_buf, >2828, >0001, >000d text 'DSK1.OVERRIDE' pab_read3: data >0214, pab_buf, >2801, >0002, >000d text 'DSK1.OVERRIDE' pab_close_read: data >0115, pab_buf, >2800, >0000, >000d text 'DSK1.OVERRIDE' Executed one by one with some additional glue code, the read operations return (without error): record 0 record 0 the first char of record 0 Why does the program read record 0 three times in a row, instead of advancing to record 1? (It should be noted that I do not update single bytes in the PAB from one operation to the next, but overwrite the entire PAB according to the list above. But I don't know which secret information should be lost this way.)
  8. Good point. I actually did make an interesting observation a while ago when I did a logic trace for Tursi. So yes, I'll keep working on the FinalGROM, although my priority is to get stuff working for Leicester.
  9. Over the past few days, I worked on the Mini Memory image with saving option, first released here. As discussed before, the problem with that image is that it overwrites some bytes in the range >7000 to >7200. The TI 99 communicates with the FinalGROM via a sequence of bank switch-like writes to >6000 and >7000 + (b << 1), where b is the byte to send. In the original Minimem image, the code would simply CLR *R1 ; R1 = >7000 + b << 1 thus overwriting the bytes, because the range >7000->7FFF is configured as RAM. The obvious solution is to replace CLR by this sequence instead: MOV *R1, R0 ; R1 = >7000 + b << 1 MOV R0, *R1 or just MOV *R1, *R1 I tried this before, but surprisingly the FinalGROM wouldn't recognize the sequence at all any more. Looking at the VHDL code for the CPLD now, however, I noticed that the detection logic for this exact case used a latch, acting on ROMS* = 0 & WE* = 0. Latches are generally not recommended, but back in the day I didn't know how to use an edge trigger for either ROMS* or WE*, since the order of the individual signals ROMS* and WE* is undefined. So now I simply introduced a new signal for ROMS* && WE*, and edge triggered that, which works perfectly -- not sure why I didn't consider that earlier. Anyway, there is now a new Minimem image fg-minimem-2.zip, and you also need to update the CPLD "firmware". For the latter, please follow the instructions on the home page, in section "How to Update". This update won't bump your displayed version number, though, as the change is pretty small. If you're not interested in using the Mini Memory and saving the contents back to SD card, you don't need to update at all.
  10. There was some discussion a while ago about the FinalGROM overwriting some bytes in the RAM area when writing back to the SD card. The solution was first to change the addresses of those bytes, but later it occurred to me that I just needed to read those bytes first. To be honest, I'll have to recheck which version I'm shipping now with the FinalGROM. I may also have to re-create the Minimem image. BTW, this thread is for the older FlashROM. For the FinalGROM, see here.
  11. Since comments about the FinalGROM keep on ending up in the FlashROM thread, I'm bumping this thread to make it more visible for people looking for the FinalGROM.
  12. I've rolled all my previous changes up into a new release 2.0.1 (grab the xdt99.2.0.1 archives, not the source ones). This will be the last Python 2.x-only release. The next release will by Python 2.x and 3 enabled, as I'm starting to prefer Python 3, and Python 2 support will end this year.
  13. My FinalGROM 99 is the successor to the FlashROM 99. The FinalGROM runs ROM, GROM and mixed ROM/GROM cartridges, and features 1 MB of RAM for images, among other improvements. You can get it from me via email, from Arcadeshopper (who sells my carts), or various other sellers offering clones of unknown quality throughout the web. The demo you saw could only handle single-bank GROM images, at least at the time. If you don't need an SD card for supplying images, there's also the very capable UberGROM (also at Arcadeshopper).
  14. Indeed. The value of s#X is the difference of X and Y, where Y is the next label following X. So this works for . greet: text 'HELLO!' byebye: text 'GOOD BYE' textend . where s#greet is @byebye - @greet and s#byebye is @textend - @byebye. If textend were missing, s#byebye would not yield the correct result, or throw an error. Also note that the number of statements/directives following the start label is irrelevant: . aa: data 1 byte 1, 1 text 'XX' bb: text '....' . In this example, s#aa yields 6. There's one special case for an odd number of bytes: . greet: text 'HELLO' weight: data 69 . Here, the difference between weight and greet is 6 bytes, because weight is even-aligned. xas99 keeps track of this, so in this case s#greet actually yields 5. Again, this applies to all kind of statements, not just TEXT. s# will not include the padding byte. When using s#, you need to make sure that there's a label after the thing you want to size. In general, this happens naturally, with the possible exception of the last element in a source file.
×
×
  • Create New...