4 ms·

Designer of the rosco-m68k (which was mentioned in another comment - thanks!) here, always good to see another 68k SBC on the block. Looking forward to seeing h

Designer of the rosco-m68k (which was mentioned in another comment - thanks!) here, always good to see another 68k SBC on the block. Looking forward to seeing how this evolves, would be especially nice to make it so $0 isn’t permanently a ROM address (to allow interrupt vectors to be changed). Even on 68010 I had to do some magic in the address decoder to make ROM be temporarily at $0 at reset.

Teknoman117 6y ago
Most of the boards I've seen that solve this have a shift register that counts the first 4 bus cycles. The data in pin is tied to 5v and the reset is tied to the reset pin on the 68k. IIRC, the clock pin is connected to the AS signal. If the 5th bit is zero, the ROM is selected. The addresses written into the first 8 bytes of the ROM are the initial (supervisor) stack pointer (typically the end of your RAM for embedded systems) and the ROM entry. At the start of the 5th bus cycle, the 5th bit goes high and the ROM is no longer mapped to the lower addresses and the CPU has jumped to the true ROM entry point. You could also of course have a register to flip the ROM being active in the lower addresses (default selected) that you later disable. You can also make a nifty DTACK generator by using another shift register. The clock is attached to the system clock, the data in pin to 5v, and the (synchronous, active when AS is deasserted) reset pin to AS. You then just AND'd the output of your chip select generators and an output bit of this shift register. (N)OR all the AND gate outputs together and wire that to DTACK (active low for the DIP parts). The first rising edge of the system clock after AS is asserted is the exact clock phase that DTACK should be asserted for a 0 wait states. Anything AND'd with the first bit of the shift register is a 0 WS peripheral, the second bit is 1 WS, third bit is 2 WS, etc. The DTACK de-assert at the end of the bus cycle also works correctly. AS deasserts in S7 (which is a falling edge of the system clock). The next rising edge of the system clock is in S0, which is when DTACK is supposed to be deasserted. (since the reset is synchronous, the clock edge will cause the shift register to reset and all the outputs will go low) My current side project is interfacing a 68010 (12.5 MHz) to an FPGA. Most of the issues are the bus voltage-level translation since all the FPGAs are only 3.3v tolerant these days. I have machinations to build a paged MMU for it that can address more than 16 MiB. I'd like to use a bigger m68k (68030 / 68040) in the future, but I'm starting with what I'm more comfortable with. the "Texas Cockroach" chips have fewer signals to worry about. Also, learning KiCad and how to use PCB-Way assembly since I have trouble with small surface mount parts (high-speed/density bus translators, currently designing with the 74LVC16T245). It's a bit hard to stay motivated when someone with a bit of patience and motivation (and have taken a decent computer architecture course) can build a 100+ MHz 32-bit RISC-V system in verilog on a ~$100 FPGA devkit.
- cmrdporcupine 6y ago
  The Atari ST had its own way of dealing with this that didn't use the standard 68k trick. As explained by EmuTOS contributor, Vincent Rivière: "Note that such "standard trick" is not used on Atari ST hardware. The first 8 bytes of the address space are always remapped to the start of the ROM. So the first 8 bytes of RAM are always inaccessible, as they are shadowed by the ROM. Actual usable RAM starts at address 8, even of cold boot." Basically as I understand it, RAM "starts" at 0x000000 but is only writable at 0x000008 and beyond. So the first 8 bytes is actually ROM and be used to jump to the rest of the ROM. The rest of the vectors after 0x000008 are written to by the OS as it boots. A little fiddly in the address decoder, but maybe less complicated than timer tricks and the like. Your 68k + FPGA project sounds interesting. There's another one that's been discussed on the EmuTOS list lately, that is using an older MAX10 FPGA which is 5v tolerant. But 68000, not 68010. I think mainly because the 68000 was produced in packages that could do higher clock rates, while the 68010 never made it above the low teens. But have you thought of just using Coldfire?
- noone_youknow 6y ago
  You're right that's how most boards handle having ROM low for the first four cycles, and that's how mine does it. I use a 74LS174 hooked up just like you say. Early in the project I did a DTACK generator similar to what you describe, but now it's handled by a GAL which allows it to be zero-wait-state in certain address spaces while supporting external DTACK for IO devices. This also allows me to easily tri-state the signal do expansion boards can generate their own DTACK. Your side-project sounds interesting, I'd love to take a look :) is it online anywhere?
  - Teknoman117 6y ago
    I've got to actually start writing things down about my personal projects :) At this point I've still just been learning about the bus timing. I've got an m68k hooked up to an 16 MHz Arduino Mega which is running the m68k at 4 MHz so I can get 4 samples per clock of the m68k (https://imgur.com/CxSlIHL https://imgur.com/CxSlIHL). I can actually drive the CPU with the arduino since I can manage DTACK just quick enough with some inline AVR assembly. Hit a small snag though. Turns out the 68010's I ordered are fakes. Ended up with the same parts you did (saw your post at https://hackaday.io/project/164305-roscom68k/log/175626-fake-mc68010s https://hackaday.io/project/164305-roscom68k/log/175626-fake...) (what I received: https://imgur.com/WCwRpHJ https://imgur.com/WCwRpHJ). I was fairly naive to the fakes when I started ordering parts. I've basically ended up with all fakes. Got some Harris 80C286-25s which are fakes (internet seems to suggest they are rebadged 20 MHz parts, so at least they are the same base part (static core 286)), but I don't have the capacity to test them quite yet. I've also ended up with a 50 MHz 68030 that seems to actually be a 33 MHz 68030. Again, I can't test it yet so I'm really hoping it's not an EC part rebadged. I wanted the MMU.
kabdib 6y ago
Same issue on the Atari ST; the custom chips just permanently mapped the first 8 bytes of RAM to the first 8 bytes of ROM. The remaining vectors stayed in RAM. Other systems I've seen just put a ROM at 0x00000000 and do an indirection (just a couple instructions of overhead).
msarnoff 6y ago
Author here. I really like the rosco-m68k! I never intended my project to be a "competitor"--one day I saw that Jameco was selling 68000s, ordered a couple, and designed this board to "scratch an itch" and learn about the 68k. It was a quick and dirty project, hence the cut corners w.r.t. memory map and ROM fixed at 0x000000.
- noone_youknow 6y ago
  Hi! I got started pretty much the same way, I used the 68k family a lot many years ago, but then a couple of years ago I randomly decided to order a 68010 that popped up on eBay and, well, here we are! I love seeing other boards, and don't think of it as competition - I think the more of us there are keeping this stuff alive, the better! I really like your project, I'll be keeping an eye out for updates :)

Teknoman117 6y ago

Most of the boards I've seen that solve this have a shift register that counts the first 4 bus cycles. The data in pin is tied to 5v and the reset is tied to the reset pin on the 68k. IIRC, the clock pin is connected to the AS signal. If the 5th bit is zero, the ROM is selected. The addresses written into the first 8 bytes of the ROM are the initial (supervisor) stack pointer (typically the end of your RAM for embedded systems) and the ROM entry. At the start of the 5th bus cycle, the 5th bit goes high and the ROM is no longer mapped to the lower addresses and the CPU has jumped to the true ROM entry point. You could also of course have a register to flip the ROM being active in the lower addresses (default selected) that you later disable. You can also make a nifty DTACK generator by using another shift register. The clock is attached to the system clock, the data in pin to 5v, and the (synchronous, active when AS is deasserted) reset pin to AS. You then just AND'd the output of your chip select generators and an output bit of this shift register. (N)OR all the AND gate outputs together and wire that to DTACK (active low for the DIP parts). The first rising edge of the system clock after AS is asserted is the exact clock phase that DTACK should be asserted for a 0 wait states. Anything AND'd with the first bit of the shift register is a 0 WS peripheral, the second bit is 1 WS, third bit is 2 WS, etc. The DTACK de-assert at the end of the bus cycle also works correctly. AS deasserts in S7 (which is a falling edge of the system clock). The next rising edge of the system clock is in S0, which is when DTACK is supposed to be deasserted. (since the reset is synchronous, the clock edge will cause the shift register to reset and all the outputs will go low) My current side project is interfacing a 68010 (12.5 MHz) to an FPGA. Most of the issues are the bus voltage-level translation since all the FPGAs are only 3.3v tolerant these days. I have machinations to build a paged MMU for it that can address more than 16 MiB. I'd like to use a bigger m68k (68030 / 68040) in the future, but I'm starting with what I'm more comfortable with. the "Texas Cockroach" chips have fewer signals to worry about. Also, learning KiCad and how to use PCB-Way assembly since I have trouble with small surface mount parts (high-speed/density bus translators, currently designing with the 74LVC16T245). It's a bit hard to stay motivated when someone with a bit of patience and motivation (and have taken a decent computer architecture course) can build a 100+ MHz 32-bit RISC-V system in verilog on a ~$100 FPGA devkit.

cmrdporcupine 6y ago
The Atari ST had its own way of dealing with this that didn't use the standard 68k trick. As explained by EmuTOS contributor, Vincent Rivière: "Note that such "standard trick" is not used on Atari ST hardware. The first 8 bytes of the address space are always remapped to the start of the ROM. So the first 8 bytes of RAM are always inaccessible, as they are shadowed by the ROM. Actual usable RAM starts at address 8, even of cold boot." Basically as I understand it, RAM "starts" at 0x000000 but is only writable at 0x000008 and beyond. So the first 8 bytes is actually ROM and be used to jump to the rest of the ROM. The rest of the vectors after 0x000008 are written to by the OS as it boots. A little fiddly in the address decoder, but maybe less complicated than timer tricks and the like. Your 68k + FPGA project sounds interesting. There's another one that's been discussed on the EmuTOS list lately, that is using an older MAX10 FPGA which is 5v tolerant. But 68000, not 68010. I think mainly because the 68000 was produced in packages that could do higher clock rates, while the 68010 never made it above the low teens. But have you thought of just using Coldfire?
noone_youknow 6y ago
You're right that's how most boards handle having ROM low for the first four cycles, and that's how mine does it. I use a 74LS174 hooked up just like you say. Early in the project I did a DTACK generator similar to what you describe, but now it's handled by a GAL which allows it to be zero-wait-state in certain address spaces while supporting external DTACK for IO devices. This also allows me to easily tri-state the signal do expansion boards can generate their own DTACK. Your side-project sounds interesting, I'd love to take a look :) is it online anywhere?
- Teknoman117 6y ago
  I've got to actually start writing things down about my personal projects :) At this point I've still just been learning about the bus timing. I've got an m68k hooked up to an 16 MHz Arduino Mega which is running the m68k at 4 MHz so I can get 4 samples per clock of the m68k (https://imgur.com/CxSlIHL https://imgur.com/CxSlIHL). I can actually drive the CPU with the arduino since I can manage DTACK just quick enough with some inline AVR assembly. Hit a small snag though. Turns out the 68010's I ordered are fakes. Ended up with the same parts you did (saw your post at https://hackaday.io/project/164305-roscom68k/log/175626-fake-mc68010s https://hackaday.io/project/164305-roscom68k/log/175626-fake...) (what I received: https://imgur.com/WCwRpHJ https://imgur.com/WCwRpHJ). I was fairly naive to the fakes when I started ordering parts. I've basically ended up with all fakes. Got some Harris 80C286-25s which are fakes (internet seems to suggest they are rebadged 20 MHz parts, so at least they are the same base part (static core 286)), but I don't have the capacity to test them quite yet. I've also ended up with a 50 MHz 68030 that seems to actually be a 33 MHz 68030. Again, I can't test it yet so I'm really hoping it's not an EC part rebadged. I wanted the MMU.

kabdib 6y ago

Same issue on the Atari ST; the custom chips just permanently mapped the first 8 bytes of RAM to the first 8 bytes of ROM. The remaining vectors stayed in RAM. Other systems I've seen just put a ROM at 0x00000000 and do an indirection (just a couple instructions of overhead).

msarnoff 6y ago

Author here. I really like the rosco-m68k! I never intended my project to be a "competitor"--one day I saw that Jameco was selling 68000s, ordered a couple, and designed this board to "scratch an itch" and learn about the 68k. It was a quick and dirty project, hence the cut corners w.r.t. memory map and ROM fixed at 0x000000.

noone_youknow 6y ago
Hi! I got started pretty much the same way, I used the 68k family a lot many years ago, but then a couple of years ago I randomly decided to order a 68010 that popped up on eBay and, well, here we are! I love seeing other boards, and don't think of it as competition - I think the more of us there are keeping this stuff alive, the better! I really like your project, I'll be keeping an eye out for updates :)