SaturnGoddex

Glad to see I'm not the only one who thought it would be neat. I'll post again if/when I can turn my full attention to it

I did research into it, but adding DMA isn't possible (at least nicely) with how I'm handling addresses. It may be possible to implement in a later version, but I can't find any public specifications on how the Drive turbo actually operates at a low level and I don't have one to test on, so for now I'm not worrying about DMA compatibility. Honestly if I could tinker with it I could probably write a custom driver for the drive turbo that would hopefully perform as well as DMA (theoretically an 8mhz block move instruction would be able to saturate the 1mhz expansion bus anyways at 7 cycles a byte). I'm also considering if it would be faster and simpler to add some sort of SD interface on the accelerator itself. TLDR I'm going to be looking into storage options more closely once the actual accelerator is up and running, but that's a project for another day. For now, it won't have any dma capability

Still working away. I wasn't happy with the first prototype so now I'm working on the second one. I'll post when there's any major news

Hi! I've got a bit of down time while I'm waiting on another project, and I've been noodling around an idea that I was curious if anyone else would enjoy Basically it would be a cartridge based accelerator for the c128 specifically, similar to the superCPU but using modern parts, with both an 8mhz 6502 (probably a 65816 actually but that's semantics) and a much faster eZ80. Modern eZ80s can run up to 50 mhz, and take less cycles per instruction (estimates I've read say it's about 2.5x faster at the same frequency). I'd be targeting GEOS specifically, patching as many subroutines as I can to instead execute on the z80 to speed it up further. So it would be compatible with the same applications, but hopefully system calls would be much quicker. It may also be possible to add some faster storage and/or ethernet on the accelerator side of things. I'm mostly curious, this is all in the back-of-a-napkin-idea phase, but would anyone else enjoy such a thing?

From my understanding the specific write cycles are stretched when shadowing is enabled, but I could be wrong. Quickdraw routines write directly to bank $E1 so I didn't focus on chasing down that piece of minutia

So I wasn't able to make the design a vertical card, it does have more clearance the the apple squeezer. Hopefully enough to make most cards a non issue (honestly I didn't have a lot of cards to measure and compare it to). As far as clock speed goes, that's a bit of an interesting topic. Officially according to WDC all 65c816's are rated for 14 mhz. But anecdotally they can handle up to ~20 mhz consistently, especially the non dip packages. I went with the PLCC variant since it saved space, but supposedly it's more tolerant of overclocking. I don't want to ship it as anything but the stock speed the parts are rated for, but the cpu speed will be configurable from a desk accessory for those so inclined to experiment. My main goal was getting GSOS to run as smoothly as possible while maintaining good backwards compatibility and napkin math says that after I added in the vram acceleration that end clock speed (past a point) doesn't matter

Well, the prototype is away at the pcb house. Fingers crossed

The first thing (something that may or may not be something anyone cares about but me) is that this is all actual hardware, with no fpga or emulation solutions on the board. There is going to be a cpld handling some of the logic functions, but that's just because otherwise I'd have to fit around 15 random chips worth of logic gates on a board that's already a little cramped. This tickles my fancy (I've personally just never felt that excited about a big black box of an fpga doing everything, it's technically very impressive but at that point I feel like I might as well just run an emulator.) It also means that I can take out the single most expensive component from the apple squeezer and use cheaper parts that will also be more readily available. This is just speculation on my part but I'd imagine component shortages are part of the reason other new accelerators are sold out and unavailable to me, so I've been making sure to avoid any parts that'll be difficult to get my hands on. The second thing is the bottleneck the IIGS has. Writing to video ram is the biggest obstacle for games, with writes always slowing down to the 1Mhz system bus regardless of how fast the CPU is. The specific idea I'm working with is using a queue for any writes to vram. It can be filled at the full accelerated 14mhz speed, with it then saturating 100% of the bandwidth of the slow bus. Basically it'd work more like a DMA, transferring data on every single clock cycle. As far as I know, the fastest way to move data into vram is using the PEA instruction, which takes 5 cycles to put 2 bytes into vram (assuming the stack has already been set to point there). Only 2 of those cycles actually need to touch slow memory, so the hypothetical best time for something like this would be 2000 nanoseconds for the actual slow writes, and about another 214s at the 14 mhz speed. But with the queue approach, as long as it isn't full, every cycle could be accelerated, meaning the whole process would take only 357 ns. 2214/357 ~= a 6x speed increase at the worst bottleneck in the system. Even if this is only true part of the time this can be a significant performance increase. Of course, once the cpu fills the queue it'll be stuck waiting to do writes in the old fashioned slow way. But since the queue is a decent length as long as on average we're writing only 1 byte to vram every 14 cycles then it empties as quick as it fills and we remain at max speed. Factoring in other code (most programs or games are not just writing a test pattern endlessly after all) I'm willing to bet this is true more often than not. Of course though, the proof is in the pudding, and I won't know if any of this actually works out until I have the thing in my hands and test it

Howdy all, I've made this thread just as a placeholder for now, I've been working on designing a new Apple IIGS accelerator. It'll run somewhere in the range of 14mhz (though it may be possible to overclock for the bold of heart), and should be a reasonable price (especially compared to vintage ones). It will feature an integrated ram expansion and a new approach to the cache that (fingers crossed it works) might make it faster than any other accelerators at the same frequency. I don't want to make any firm promises on a timeline but a very good portion of the design is already done and I'd expect to have a prototype ready sometime soon. If you're interested, I did put together a little survey, filling it out would be helpful to me. I did add an option to leave an email address if you'd like any updates on it, but it's completely optional and any news will also be posted to this thread. Survey: https://forms.gle/C3QA4jtwn41cwDkAA Otherwise, enjoy, and fingers crossed for exciting things to come!