ralphb

Indeed. For the 378: . // Bits: 0110 0000 0bbb bbbx // x = don't care, bbbb = bank if ((offset & 0xff80)==0x6000) . Why do you insist on the upper bits being 0? This is what breaks Pac-Man. Personally, I'd make this . // Bits: 011x xxxx xbbb bbbx // x = don't care, bbbb = bank if ((offset & 0xe000)==0x6000) . Would that break other, modern programs? (I just noticed that's what you do for the 377, so why not for the 378? Is it not true to the original enough? I haven't tried it, but AFAIR the red board also ignores those bits.)

Sorry, I meant the emulation. And it's not really crashing either, but Pac-Man is stuck in it's bank-switching loop. For example, it's writing to >646c, but of course the programmers only cared about A1 (modern naming) back then. I don't know how you decode the bank switching, but I duplicating the image should nullify the larger address space when bank switching. I just thought that previous MESS versions might have a different decoding than you described above.

Ah, that's useful, thanks for the update. I guess I can live with padding for now. (My MESS still crashes on the duplicated Pac-Man w/378, whereas the original one works. I'm a few MESS versions behind, though, I'll check with the latest one again.)

Michael, what's the current status with MESS and homebrew cartridges? According to Ninerpedia, there's only 379i, but no 378. Could we get a generic 378/379 layout where we can specify the number of available banks in the layout.xml? That would make it much simpler to emulate real iron homebrew cartridges, other than the known color boards. Case in point, as a workaround I'm trying to run Pac-Man in 379i mode, so I took PACMAND and PACMANC and duplicated those 16K up to 128K, but the program still crashes as soon as Pac-Man opens his mouth for the first time. Is 379i bigger than 128K now? Configurable banks and invertedness would make it much simpler to replicate the cart one actually has. (Couldn't find the actual MESS thread anymore, but this one seems even better.)

Actually, I was thinking of a read/write counter for ALL memory, displayed in the memory window (if requested), resettable by debugger command. Like a heatmap. (AFAIK, Classic 99 has something like that, but yes, I understand the philosophical differences between those programs. ) No immediate need, though, just a nice feature.

No worries, Chris, I share your general sentiment. My interpretation of this conversation is more like "ok, now that we got this, how can we use/abuse/hack this thing to do what it's not supposed to do?" -- to me, that's the typical hacker spirit. And then everyone jumps in to discuss if this hack is possible or not, and how to do it best. The usefulness of the result is often secondary for hackers. And I like Ω's posts, as he always seeks out new "business opportunities" for everything that happens on AA, which is something I totally don't.

Thank you all for the lightning fast replies. Very handy, thanks! I'll add some mappings to that, because -- as you guessed -- I need to translate key presses A ... Z to indices 1 ... 26, for you-know-what. Hey, that's would be an awesome MESS feature! I was thinking of using the debugger to run on a pre-initialized scratch pad and to check which bytes have changed. But you're also detecting reads ... Any chance this might make it into MESS proper? And in case you're wondering ... The more scratch pad I have, the more images I can sort on the FlashROM. Otherwise, I'd have to revert to VDP RAM, which is doable, but tedious.

Ugh, what a greedy little program! Are there more economical alternatives already written that handle debouncing, and preferably return the ASCII code of the key instead of some key code? fbForth, perchance? Size doesn't matter, just scratch RAM usage.

I'd like to maximize scratch pad usage >8300->83ff in my assembly programs. What are safe addresses for my own use if I don't use interrupts, DSRLNK, or GPLLNK in my program, and I don't want to return to E/A? How does this change if I still want to use BL @SCAN (in addition to the obvious loss of >8374->8377, >837c, >83e0+)? This has probably been discussed countless times before, but Google (and the forum search) is surprisingly bad at searching AtariAge. Or I'm surprisingly bad at coming up with search words. Thierry has a nice list of the scratch pad words, but it is not entirely clear when those are used.

No, unfortunately, adding GROM support is not simple at all. In fact, it would be much simpler to add an SD card to the UberGrom than to add GROMs to the FlashROM. This is a guesstimate, though, as I've never looked at the design of an UberGrom -- on purpose, since I don't want to spoil the learning and discovery fun for me. If I ever do GROM, it will probably not be an extension, but a different design.

About the dimensions: It's 10 cm wide (standard) and 8 cm long, about 1 cm longer than a standard cart. And it doesn't have the hole in the middle. For the board in the picture I socketed the 541s towards the connector, which makes the cart a really tight fit in the cart port. There's less than a mm head room between the top of the ICs and the plastic frame of the cart port. For any kind of case, sockets are a no-go. No big deal, though; the only thing worth socketing is the big 8515. And of course cases need openings for the LED, the reset button, and the SD slot.

Tadaa! My prototypes arrived, and surprisingly they worked on first try. I do have a few spares. If you're interested in beta testing the board please send me a PM and I'll send you one for S&H. Note that this includes the board and instructions only, so you should be able to get parts, program an ATmega, and assemble the board on your own. If you don't have the tools and/or skills, PM me anyway and we'll see. But please: this is for people willing to test only! Now the actual release will follow soon. I'd like to exchange the resistors' footprint and redo the silkscreen for improved clarity. On the software side, I need to add two missing features. Once that is done, everything will be released on GitHub so you can build your own cart. If you don't have the tools (or patience) to build everything yourself, I'll be selling boards and probably assembled carts as well.

Great demo! Is plain scrolling faster then zooming or rotating i.e., could you go faster than 20 fps when scrolling? And if you used high color mode, would the result be 5 fps, or actually faster?

I'm about halfway through with the layout, but now I caught the flu. I'll keep you posted about the progress.

I'm currently at the schematics stage ... Layout will be challenging because we have two busses criss-crossing all over the board. Well, somewhat difficult. One of my early designs used a 512K SRAM chip and loaded everything up front, then the menu would simply select the corresponding bank. That wasn't very straightforward at all, and loading times are short, so I went for "load on demand" instead. You can still increase capacity beyond 32K with the current design, but the ATmega 8515 has only one pin left for addressing the RAM. This by itself would not be so much of a problem, though. In fact, I have an alternative design that uses a more regular ATmega 328 instead of the bulky but wimpy 8515. To compensate for the lack of pins I'd add two 590 8-bit counters that address the RAM sequentially -- the software is written not to use random access. But as the size requirements for 328 + 2x 590 vs. 8515 are about the same, I went for the 8515 because that would mean less wires. So you could use that approach to address the ATmega pin shortage. But the bus switch also has no free pins left. You need to switch the bank selector as well, as the 377 has no output enable. So to answer your question: A higher capacity would require two additional chips on the board, making it even larger. At this point I'd rather leave it as it is. Yes, that idea is pure genius -- kudos! That free pin mentioned above should be just right for this task ... I'll have to try this out on the weekend. This would also eliminate the need for the reset button, unless you like to have a hardware reset button anyway.

Thanks! To answer the questions: Yes, that's my plan. Right now I don't even have readable schematics, so the software alone won't do you any good. But I hope to have everything up on GitHub soon. Yes, it's like a 512K ROM board ("red board"), but you can change the games simply by swapping the SD card. No reprogramming or the like necessary. The ROM boards still have their uses, though, because they don't have a load time for the images. The UberGrom is entirely different, and still the only way to run GROM-based programs. Power is drawn from the TI, so no external power supply. The NanoPEB or the CF7+ is a disk and memory replacement. They (or an original PEB) are still highly recommended. Note that a standalone cartridge program can use only 256 bytes of RAM. Disk-based games programs rely on the 32K RAM expansion of the PEB. (But some modern carts, like JSW from Rasmus, also rely on the 32K RAM expansion.) It's plain FAT16 or FAT32, i.e., out-of-the-box SD or SDHC cards, but no SDXC cards. No special program for transferring the images to the card required. Yes, you're right. If an image has multiple entries, I include them all in the menu. Right now I set an artificial upper limit of 8 entries, but I plan to add a ninth entry "MORE ..." that will take you to a multi-cart like menu selection with the remaining entries. It's not really meant to support 8 GB cards full of images, although there's no real limit other than the limited 0.5K RAM inside the ATmega 8515 to store all the filenames. The button pressed is the RESET button. Since the cart cannot detect when I reset the console by FCTN-=, I need to reload the menu, or you'll get the menu of the previously selected card. In the end my reset button should also reset the console, but I didn't have the right kind of push button lying around, so I have to reset the console manually. Note that I want the cart to work with unmodified images, so I'm not sure one can do better than that.

UPDATE: With beta testing completed, the project has now been published. Please refer to post 72 for the release. Since January I've been working on a new project: the Flash ROM Cart. As the name suggests, the cart allows playing ROM images stored on an SD card on an unexpanded TI 99/4A. https://www.youtube.com/watch?v=RlVdV77lmsA The cart works with individual ROM banks, e.g. from RPK archives, or single non-inverted images. In the video I'm inverting an inverted image to get a non-inverted one. (For some reason the screen capture comes out quite blurry, but fullscreen is OK.) The current board uses a 32K RAM chip, so images are limited to that size. No GROMs, sorry. I'm using an ATmega 8515 to read data from the SD card and fill the SRAM chip. Bank switching uses the well-known design by Jon, this time with a 377, as those are still commonly available. The 377 is also used for one-way communication from the TI to the cart, i.e., the image selection. Alas, those parts alone won't do. In order for the microcontroller to access the RAM, the RAM needs to be isolated from the TI 99 bus. I thus added three 541 chips that will take the entire cart "offline" when the ATmega is active. This makes it unlikely to fit into a regular TI cart case, but I couldn't come up with a simpler design without resorting to SMD parts. As you can see, this is a prototype. This even started on a breadboard with an Arduino, but I soon grew out of that. I'll do a layout and get proper boards made next. Once I have that I'll publish everything up on GitHub so that other people can get their hands on it.

Thumbs up for the idea and the execution! That TI 99/8 picture page is better than pr0n!

Yes, the latest fix does just that. You can get the file from GitHub via the link above.

Good question. The GPL spec doesn't state what happens for a shift value of 0. But if GPL is like assembly then shifting by 0 actually means shifting by 16 -- which would shift all the bits away. Now GPL is 8-bit only, so it makes only half sense ... Why don't you try SRA 0,@>8300, where the original value of >8300 is >80? If the assembly theory is correct, you should get >FF afterwards. EDIT: I just remembered: In assembly, shifting by 0 means shifting by R0, and if THAT is 0, then you shift by 16. So it only makes quarter sense for GPL now.

Ha, that's actually quite a funny bug. It's been fixed on GitHub now, though. Most compilers and assemblers are multi-pass, i.e., they read the source code multiple times before generating code. The reason is quite simple: If you have a forward reference, e.g., . ... JMP NEXT <---- where is NEXT? ... NEXT CLR R0 . then you cannot create code for a jump to a location you haven't seen yet. The xas99 assembler is two-pass: The first pass reads the source code to find values for all symbols, and then the second pass generates code, substituting the previously found values for all symbols as it goes along. Interestingly, a two-pass assembler won't do for GPL. GPL has many different addressing modes for RAM, GROM, VDP RAM, and VDP registers. To save space, the language encodes addresses in 1, 2, or 3 bytes, depending on the value of the address. All ROM/RAM addresses are encoded relative to >8300, and the farther away an address is from >8300, the more bytes it takes to encode it. For example, in the instruction ST 1,@>8300, GPL encodes the @>8300 as @>00, but would encode @>8380 as @>0080 and @>9000 as @>0F1000. So if you have code like . .ST 1,@ADDR . then the compiler needs the second pass before it can generate the code for this instruction. Now look at this program (from the xga99 test suite): . S1 ST 1,@CPU1 S2 ST 2,@CPU2 S3 ST 3,@CPU3 EXIT CPU1 EQU >837F CPU2 EQU >837F+S2-S1-3 CPU3 EQU >837F+S3-S1-3-3 . The values of Sx and CPUx depend on each other, and since all CPUx values are just slightly below >8380, their encoding might be 1 or 2 bytes, depending on the size of each Sx instruction above. The first pass defines all symbols, but the second pass will move S2 and S3 as the argument of S1 has changed. Consequently, the values of CPUx will also change. In other words. the code after pass 2 is still "unstable", and thus not correct. So the GPL assembler needs another pass. This time, S3 is moved, as the argument of S2 has changed. Only in the fourth pass do all symbols remain stable, and we're done. xga99 has an upper limit of 32 passes, which is arbitrary, but 32 passes should be enough for anybody. But now back to the label bug: Because of some incorrect duplicate label check, the statement with the duplicate label changed the value of that label symbol twice per pass. xga99 correctly thought that some symbol is still unstable and triggered another pass, until we hit the 32 limit. So when I heard your error description, I knew immediately what went wrong.

Geez ... how many do you need to acknowledge a jocular encouragement?

I second this -- "busy" is a good excuse, but "lazy" is not.

Turns out it wasn't straight-forward at all , but at least now the code base of xga99 and xas99 is much better aligned again. xga99 now supports conditional assembly, and macros. So regarding your request, you can write . START .ifdef TEST DST 999,@Lives .else DST 3,@Lives .endif DST 1,@Index and assemble with . $ xga99.py sample.gpl <--- 3 lives $ xga99.py sample.gpl -D TEST <--- 999 lives . You can also assign values, so you could write . .ifdef TEST DST TEST,@Lives .else DST 3,@Lives .endif . and assemble with . $ xga99.py sample.gpl -D TEST=69 . You can also use macros now, but note that I don't support the "default" macros like $WHILE etc. yet. Please get the updated xga99 from here, as there's no new release yet. The manual has also been updated, but you can just have a look at the matching sections for xas99. Edit: That forum editor is killing me ...

Yeah, I see your point. I think it should be straight-forward to port the pre-processor from xas99 to xga99. I'll give it a shot on the weekend.