MOS_8502 🇨🇦
@studio8502
(He/Him) Retrocomputing Maker and Designer in Ontario, Canada.
Critique my audio mixer. This is meant to mix two line-level audio signals in stereo, coming from the VERA's PSG and whatever the cartridge decides to put on its outputs. This is to enable expansion audio.
Hive mind: Recommend me an op-amp from JLCPCB's parts library for OA1 in this schematic.
I'm mulling over the possibility of replacing the PLCC ROM socket with a DIP socket. PLCC ROM is slightly cheaper, but more fragile, and requires an adapter to burn new ROM images to it.
The intended model of use is to put a SNES controller in the left port, and either a second SNES controller or a SNES mouse in the right port. It takes an 8MB ROM cartridge or RAM expansion, and can use microSD for mass storage.
It's routed, and it passes DRC. If my keyboard design is right, then it will work, otherwise it'll waste an awful lot of money.
I think it's looking pretty good actually. Very "SNES meets MSX". Which is what I was going for.
There. Key switches and diodes laid out. Note the Commodore style F-keys in a block above the inverted-T cursor, the left and right Meta keys by the spacebar, and the Control key to left of A.
Beginning to lay out the key switches. Note that Control is to the left of A, where it fucking belongs.
The sad part for me is that I know it's a more or less bespoke design, but it looks like it came out of a white box in a warehouse in Shenzhen. There's just no escaping the "flip phone" aesthetic looking cheap. It could have just as easily been a slab with a physical keypad.
This was a good idea that couldn't be executed properly in the 1980s. Stick Android on a device like this (with a touchscreen OLED screen obviously) and you got something people haven't seen 1,000 times before.
I will be sad if tomorrow obsoletes my baby, but I will stiff upper lip and carry on regardless.
These three chips form a very cheap and cheerful four-bank paged MMU. I got the idea from the Zeta SBC, but I adapted it to my needs, and expanded it with a programmable logic device to handle the address decoding and control over the bank output.
That's so much smaller. All in production parts. Under the magic 100mm square limit for cheap PCB fab. 512KB ROM. 512KB RAM. Arbitrary mapping to four banked 8KB ranges, plus fixed RAM and ROM ranges to boot. #c64 #commodore #programming #retrocomputing
New idea for banking hardware. This puts four bytes of RAM at 0xDE00-0xDE03. Each of those bytes can map an arbitrary 8KB bank of RAM or ROM to one of four decoded 8KB ranges.
Is this clever or dumb: I added a tristate buffer and pullups between the bank register and ROM, and wired it so that when the /ROML signal goes low, it reads the selected bank, but when high, it reads the topmost bank instead, for a fixed 0xE000-0xFFFF and a banked 0x8000-0x9FFF with one ROM chip.
Confession: I'm shit at 2d fighting games. They bore me senseless. The only series that's ever held my attention long enough for me to get kind of okay at it was Darkstalkers.
This here is about the simplest practical design I've got in me. It bank switches 512KB of VIC-II ROM from 0x4000-0x5FFF, 512KB of CPU ROM from 0xE000-0xFFFF, and 32KB of VIC-II RAM from 0x6000-0x7FFF. Seven chips. A bit large compared to most C64 cartridges.
It's just barely possible that we've worked out how to hack the C64's cartridge port to enable bank-switching the video memory -- something thought impossible. Imagine preloading all your assets into ROM, and having them two instructions away from being directly visible to the VIC-II.
AI bollocks makes me think of this book by Larry Niven: World of Ptavvs. It's about a race of beings who are not particularly smart, but who have the ability to enslave smarter beings and make them work for them. It doesn't end well for anyone.
First test rendering of a maze for that Rat Burglar thing I was working on before.
The memory map for my cartridge framework has grown a bit. But in a good way, with space reserved more accurately for handling sound effects and music.
With very careful technique, I have managed to squeeze in 41.99KB of program code space, by banking out the KERNAL entirely and making use of the memory under I/O for sprite bitmap storage.