A3000/4000 1MB ROM Mod

I have seen his blog post about it and it was really nice.
The proto board is just full of win!!!

Nice job to both of you guys \o/
 
Looking very good! :)

Now, when do we get to see Romy on top of Fat Gary? ;)
 
You can try also new ROM parts rewriten in assembler from Don Adan. You will gain some more space in ROM.
 
Hi all.

It works on Amiga 4000T ( amiga technologies ) ?
If yes ... can someone burn that rom for me? I will pay that job and roms :p

Best Regards
Pedro Henriques (y)
 
I can burn those chips, do not have a 4000T for testing however - so I cant answer that part.
 
** 6TH NEWS UPDATE **

Romy rev. 7 has been uploaded to post #1. Rev. 7 can run a 3 clock bus cycle if you have fast enough ROM's! You should have 100 ns ROM's (but maybe 120ns ROM's are fast enough*). The schematic has been revised slightly to show DSTERM as an option output. So the Speed jumper now selects a 3 or 4 clock cycle on STERM and a 5 or 6 clock cycle on DSTERM.

If you have fast enough ROM's to use the 3 clock cycle option you may want to change your ROM building strategy. (i.e. moving important modules into extended ROM).

*Note: Unfortunately, the A3000 has 1K pull-up resistors on the address and data buses. (IMHO this a design bug). I changed mine to 3.3K to improve address and data valid times but it involves a fair amount of work.
 
Last edited:
** 7TH NEWS UPDATE **

Romy rev. 8 was uploaded to post #1. Functionally, it's the same as rev. 7 but should be more reliable on over-clocked motherboards. Previous versions of Romy used asynchronous reset on all registered outputs to simplify the logic and because I wanted to make earlier versions as bug free as possible. Rev. 7 worked fine @ 25 MHz but would probably not be able to run a 3 clock cycle @ 33 MHz. Due to shorter cycle timing Romy would have approx. 10ns less time to come out of reset and sample clock 90. (Even a 10ns GAL may not be fast enough when you factor in 10-15ns delayed AS assertion). So this version replaces asynchronous reset logic with AS negation and flip-flop logic to set all registers at cycle end.

Now, to make things a little more interesting here are my (CPU nodatacache) Bustest results for the 3 clock cycle! :cool:

68030 @ 25 MHz:
BusSpeedTest 0.19 (mlelstv) Buffer: 262144 Bytes, Alignment: 32768
========================================================================
memtype addr op cycle calib bandwidth
user $00E00000 readw 242.9 ns normal 8.2 * 10^6 byte/s
user $00E00000 readl 243.9 ns normal 16.4 * 10^6 byte/s
user $00E00000 readm 222.7 ns normal 18.0 * 10^6 byte/s
user $00E00000 writew 161.8 ns normal 12.4 * 10^6 byte/s
user $00E00000 writel 161.9 ns normal 24.7 * 10^6 byte/s
user $00E00000 writem 146.9 ns normal 27.2 * 10^6 byte/s

68040 @ 50 MHz (Romy @ 25 MHz):
BusSpeedTest 0.19 (mlelstv) Buffer: 262144 Bytes, Alignment: 32768
========================================================================
memtype addr op cycle calib bandwidth
user $00E00000 readw 201.6 ns normal 9.9 * 10^6 byte/s
user $00E00000 readl 201.9 ns normal 19.8 * 10^6 byte/s
user $00E00000 readm 206.5 ns normal 19.4 * 10^6 byte/s
user $00E00000 writew 120.5 ns normal 16.6 * 10^6 byte/s
user $00E00000 writel 120.5 ns normal 33.2 * 10^6 byte/s
user $00E00000 writem 121.1 ns normal 33.0 * 10^6 byte/s

Note: This time I've included write cycle benchmark results to give you a better idea of how fast the cycles are going from Romy's point of view. Do you suspect 68K read instructions execute more slowly than write instructions? Do you suspect Bustest calculates the results differently for read and write cycles? However, my Fast memory Bustest results are the same on both read and write! :blink: Bustest does attempt to "compensate" for instruction execution time but it's very hard to make an accurate benchmark program because of:

MOTOROLA MC68030 USER’S MANUAL

11.1 PERFORMANCE TRADEOFFS
The MC68030 maximizes average performance at the expense of worst case performance. The time spent executing one instruction can vary from zero to over 100 clocks. Factors affecting the execution time are the preceding and following instructions, the instruction stream alignment, residency of operands and instruction words in the caches, residency of address translations in the address translation cache, and operand alignment.
 
Last edited:
** 8TH NEWS UPDATE **

I have completed a PCB design for the A3000! It's the tower PCB design described in post # 17. It will take some time to get a prototype PCB made and tested but I thought you might want to see an early preview and some considerations for this design:

- Eliminates all motherboard jumper wires except A19 to ROMs.
- Does not require SMD soldering skills or equipment
- Requires desoldering Fat Gary PLCC socket
- Requires a PLCC wire wrap socket or extension pins soldered to original socket (See example pdf attached)

If the prototype PCB test goes OK then I'll upload the Gerber files to this thread.

The link for images and downloadable files is here:

http://eab.abime.net/showthread.php?p=783399
 
Last edited:
Nice stuff :)

So the socket on this pcb goes over fat gary (like an indivision aga), that's the reason for desoldering the mobo gary socket (if any) ?

why would a wire wrap plcc socket be needed? would one for through-hole mounting not suffice?
 
@SpeedGeek: IIRC, there was a guy some years ago that show the place in the A4000 where one can install the PLCC GAL directly.

C= did the board with the spot ready to go. Too bad management, as always, cut the cost of 1Mb ROM capability from the start.
 
@hooverphonique

No, the PCB and PLCC socket replace the Fat Gary socket so the pins must be long enough to extend through 2 boards. As previously mentioned, an "Indivision" style PCB is only practical for the A4000.

There are some PLCC socket extenders and prototype adapters available but they are very expensive so I have chosen the lower cost alternative. A second problem is space is very limited on the A3000 motherboard so if a tower PCB extends to far forward, right or left it blocks access to J104, J150, J151 or the center hole mounting screw! :eek:

@rkauer

I believe your are referring to the A4000T my friend! However, there is no such place for a PAL/GAL in the A3000D/T or A4000D. Also, please remember that Romy now provides faster ROM access than Fat Gary! I even have an experimental version which supports up to 4MB of extended ROM! :cool: Oops, I wasn't supposed to let that slip!

@mfilos

Thanks for the good word my friend! :) Doobrey sent me a modified MMUlib and remapper archive which eliminates "DummyCDstrap" and supports up to 2MB of extended ROM! Hopefully, he will post this along with the next Remus update but I could email this "Beta-ware" archive if requested.
 
Last edited:
Next version of Remus would be full of win :p
I wouldn't mind the archive if possible. I'm sure Doobrey won't mind as I'm beta testing Remus as well :)
 
** 9TH NEWS UPDATE **

After very many hours of hard work the A3K ROMY prototype PCB test was successful! :)

Whew! I really made this tower PCB the hard way! By cutting and stripping 84 pieces of solid copper wire (approx. 1.4 cm) and soldering them to the bottom of the PCB and original Fat Gary PLCC socket. The wire wrap PLCC socket could save some work here at additional cost.

A small section of the PCB can (optionally) be cut out to allow easier access to the 74F08. See updated images in posts #1 and #48.

If you think this project is too difficult or complicated then you are certainly welcome to design your own plug in PCB for the A3000 (or A4000). ;)

P.S. Now I can say I have a "Romy" tower in my A3000! :LOL:
 
Last edited:
OMG how dare you not putting a single image of this fine pr0nfest???
Come on!!!

(waiting patiently)...
 
mfilos my friend. The new images in posts #1 and #48 are the very best my el-cheapo DSC can provide! ;)
 
Awesome man!!! Truly nice work!
Gief version for A4000 now hahaha :)
 
Nice stuff, man.. looks like a lot of fiddly work ;)

what happened to the A19 wire? did you put that on the underside of the mobo?
 
At the risk of bringing this potentially back to US politics (about which I have no desire to learn more)....

How about naming it "Fat Hillary" for no particular reason... we have Fat Gary for example ;)
 
Back
Top Bottom