ralphb

Thanks for the feedback. I've just had an idea how I could merge both proposals, but I need to verify it first on the weekend.

I'm currently working on a "RAM mode" with RAM support (not GRAM!), and I'd like your feedback on this matter. Right now I favor to have a ROM section from >6000 to >6FFF and a RAM section from >7000 to >7FFF. A bank switch is done by writing to >6xxx, while writing to >7xxx will update the RAM value. This is quite simple to implement. IIRC the Wiesbaden Supermodule did it like this, and it also looks like the MiniMem. The ROM area could be reduced down to >6000->6100. This is the smallest area that needs to be reserved for bank switching to work. But having a smaller ROM area makes the internal logic mode complex, which is why I favor the 4K/4K variant. Now the main question is: Should the RAM be shared by all banks, or does each bank have its own 4K of RAM? The first version is much simpler to program for, but it has only 4K of RAM instead of the 256K of the second version. Can some developers comment what they would prefer (other than "both" )? Note that RAM mode will be a special mode that programs will have to choose; it's not the default for legacy programs. In other words, backward compatibility is not an issue here.

Well, it depends on how much logic I can fit into the CPLD. XB is an extra rule, GRAM is an extra rule, GROM 0-2 is an extra rule ... But yes, I'll try. EDIT: Just for clarification, I don't think there'll be a battery ...

Sounds like a deal, I guess.

Oh, good to know! Better not bid on that one then ...

What happened to this keyboard? http://www.ebay.de/itm/172530161735 Never seen that font, and no FCTN symbols either? (Well, no symbols could be the lighting, though.)

Yes, that could be useful. But unless someone writes txt files for all the old programs, there won't be a lot of text files. And for new programs, you could just include the description inside your program (but you couldn't read it before loading it). I'll keep it in mind, though, like many other things ... maybe I'll implement some suggestions via updates.

Owen, download and install Python 2.7.13 from this site: https://www.python.org/downloads/ Once that is done, open a "command line", i.e., run "cmd.exe". Now inside the cmd.exe window, type "cd c:\xxx", where xxx is the path of the xdt99 suite where all x*99.py files are located. When there, type "xga99.py", and you should see a help page. If that doesn't work, let me know which step breaks for you. Edit: typo

If I may speak for Rasmus, it's DSDD 40T. See my corrected disk image some posts above.

You're right, Michael, but with the current version of xdm99 the sectors per track is correct. I attached a corrected version: demo-dsdd-fixed.dsk

Duh! But kudos for publishing the code! This will be a great inspiration and learning resource for others.

Congratulations, an incredible demo! My favorites are "snakes" and "3D Xevious", but the three-graphics-mode-in-1 is the most surprising. I'm not sure if it has been answered before, but: Are you going to release the source code? Or is that some kind of trade secret in the demo scene?

Wow, that's great! I'll add "Also works for TI 99/8" to the homepage, I'm sure it'll increase demand.

Fun sure feels like work sometimes.

Thanks for all your enthusiastic comments so far, but unfortunately I have to put a little damper on your expectations regarding completion of the project. When I did the video above, the prototype did have some instability in reading data from the cart ROM space, of all things. More precisely, when running a ROM test program, every few minutes a wrong value is read, and then the error is gone until the next error (at the same or a different address). I thought it would be just a matter of rewriting the VHDL code inside the CPLD, but it turned out I was wrong. Since that video, the cart has been driving me crazy. What I found out so far is that the read errors follow a pattern. It's always the high byte of a word that is corrupt, and the bad byte value read isn't stored anywhere in the entire SRAM. . Expected Actual >6F10 >3510 >6F82 >2F82 >6D00 >FD00 . So I tried to find the error with my scope. This is what I got so far (start top left and read counter-clockwise): These four diagrams are from different measurements/read errors, but they all show Bit 4 for a muxed word read. My test data in the cart is so that each address contains the address as value, i.e., >6100 stores >6100, >6102 stores >6102, etc. The errors shown in the diagram are all at addresses for which Bit 4 should have been 0 for both bytes, for all diagrams. As you can see, this only holds true for the bus address and RAM address. The RAM data is erroneous, but I still don't know why. Two weeks ago I contacted Jim (brian) and later Erik (speccery) about these issues and asked for help. We've been discussing since then, but haven't found anything conclusive yet. I still think this can be fixed, but please understand that the cart won't be done as soon as we all hoped.

The Game Genie allowed you to override some values in ROM, and you entered codes for address to modify and their new value. That way you could modify the number of initial lives from 3 to 256, get invincibility, and so on. The biggest problem is to find those codes. There's an article in the last RetroGamer about the Game Genie and how they trial-and-error'ed those codes. For example, they'd modify each memory location containing a 3, one by one, to see if the number of initial lives would increase. But assuming we have those codes, since all images are modifiable, you could just change PARSECG.BIN (as an example) and load that into the FinalGROM. There'd be no codes, you can just use modified image files. But you need to know which addresses to modify.

Thanks , but it probably wouldn't have prevented this. I was picking up the cart just because I wanted to insert a SD card, and a fat finger touched the solder points of the µC, which fried the connected CPLD. It would have to be a very long strap that I could wear while rummaging around my lab.

Thanks for the offer, but no worries. For the prototype I got 10 PCBs with parts, and the fried cart was #6. Cart #7 has already been built and is running again.

Oh, and last night I frizzed my dev board by touching it. I could feel the static in my fingers. Probably it wasn't the best idea to put a shag carpet right in front of my solder workplace.

Interesting technique! I didn't think of interrupts. The µC still has the same jobs as in the FlashROM, mostly SD card handling and image generation. The CPLD handles the SRAM (i.e., all ROM and ROM reads as well as the sequential µC writes), switches the banks, and emulates the GROMs. There are some irritating resource drainers like the bank register, the bank mask, the current GROM, the GROM mask, the selection register ... it quickly sums up. Originally I tried to use just one address counter for both GROM and RAM loader, but the mess ... all in all I'm at about 96 macrocells now, but it's not done yet. The µC cannot write directly to the RAM, as there are not enough pins on the µC. I also thought about serial RAM, but I figured it might not be fast enough.

Thanks for that summary, Tursi! So in other words, I would have to implement address read anyway, right? Let's see if I can add another rule to the GROM address register.

Thanks for your suggestions, Jim. I'm writing any value to >70xy, where xy is the value I want to send. And I write anything to >6000 to signal the microcontroller that a new byte will be sent. Yes, I could write xy to >6000 instead, but I'd still need some sort of marker bit. I guess I could alternate between sending xy and 00. But mostly I adopted this method from the FlashROM, which had no other way of transmitting data than using the bank switch register. There's no shortage of pins on the microcontroller, so I kept it. Yes, that's a method I had detailed to Rasmus somewhere in the FlashROM thread, where he raised this request as well. In fact, I probably wouldn't implement this in the CPLD, but in the microcontroller. Alright, I'll think about this ... but there's a lot of stuff to think about now!

Yes, the 95288 would be the end of the Fahnenstange. I started with the 9572, but when I put both GROM and image loading in it would no longer fit the 9572. The 95144 still complains about things, so maybe I'll have to move pin assignments a little. But the 95288 costs €18, whereas the 95144 can be had for €7, so I'll stick to the 95144. The CF7+, by the way, uses a tiny 9536, but then I guess there's some additional logic in the piggy-back adapter. I'll send you a test board when they're ready. I haven't tried it yet. I'd also need some extra logic to tell console GROMs from cart GROMs. But someone said that the GRAM Kracker "just shouts louder", so maybe it could work. Thanks again for that suggestion, but to be honest, this has probably the least priority for me. Which doesn't mean I won't try it, but if I have to choose between some additional features then GRAM will be out. Ouch, now that's a very good point! So far, it is ROM, and I'm not really in the mood to rewrite the menu in GPL. Let's see if a wrapper will do. In theory yes, but it depends if it fits into the 8515, which has barely any bytes left. I'll try further down the road, but it's pretty unlikely. The FinalGROM has 16K of program space, whereas the FlashROM only had 8K. No, sorry. That'd be too much magic. It's not that easy. The main problem is that you'd have to distinguish bank switches from image selection. Selecting a game is alternating writes to >6000 and >70xy, where xy is a byte of the filename you want to load. Right now bank switches and image selection are temporally separate, but if image selection must always be active then you have a conflict with games like Pac-Man that use absurd addresses for bank selection, which would be interpreted as image selection.

Thanks for the correction, Lee! I shouldn't write sentences that start with "if I remember correctly ...".

If I remember correctly, this is the behavior of the original E/A module. EQU expressions must be "well-defined", i.e., their value must be known in the first pass, so forward references are not possible. I'm not sure if you can relax this and still have a two-pass assembler, but I might give it a try at some point. Edit: typo