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.
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?
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). 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.
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.
Awesome :) I've played around a bit interfacing Arduino to mine too, and found I had to use AVR assembly to get the timing right.
Yep, those are exactly the same as some of the fakes I have here. Adeleparts definitely rings a bell as the source of some of mine too.
Sadly it seems to be quite common to remark the "lesser" 030/040/060s to suggest they are the fully-capable ones :( Fingers crossed yours isn't like that!
If you don't mind me asking, do you know what the fan-out capability of the "big DIP" m68k's are? I've not noticed a hobby board built around one that has bus transceivers or line drivers, but all of the boards built around things like the 8088 and 8086 have them. I know those required latches to de-multiplex the bus, but the datasheet for the Intel parts recommend line drivers and bus transceivers except for simple "minimum-mode" systems.
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.
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.