ROM preferences

[cbmeeks]

What ROM component are you guys using these days? (assuming you're not ROMless or things like that).

The AT28C256 hasn't been cheap in a long time and I guess I have a hard time paying nearly $7 for 32 KiB of ROM. Plus, they're a little slow.

This seems better at 128 KiB and 70ns (~$2):
https://www.mouser.com/ProductDetail/Gr ... 8zCtxnc%3D

But I've never tried it. I don't know why it wouldn't work.

Anything I'm missing? I prefer 5V and through-hole....at least for my current project.

[Martin A]

I've been using the SST39SF0x0 family with both the Z80 and 65C02 families.

It's 5v, through hole and has an order of magnitude more programming cycles than the 29 series flash.

The 70ns rating is pretty conservative, as I have it running on boards with a C02 at 16mhz.

[thedrip]

I also use SST components. In my case the SST27SF512. I bought 100 units a decade ago for a project that never happened.

Currently in my own SBC design at 4MHZ. It doesn't run at 8, but I have not diagnosed what component is causing issues.

[BigDumbDinosaur]

cbmeeks wrote:

What ROM component are you guys using these days? (assuming you're not ROMless or things like that).

The AT28C256 hasn't been cheap in a long time and I guess I have a hard time paying nearly $7 for 32 KiB of ROM. Plus, they're a little slow.

This seems better at 128 KiB and 70ns (~$2):
https://www.mouser.com/ProductDetail/Gr ... 8zCtxnc%3D

But I've never tried it. I don't know why it wouldn't work.

Anything I'm missing? I prefer 5V and through-hole....at least for my current project.

My go-to ROM for some years has been the AMD 27C256-55 (55ns). Alas, the product has become hard to obtain.

[BillO]

+1 for the SST EEPROMs. I've used the 27SF256 in both 55ns and 70ns. I have several 65C02 boards running up to 16MHz with the 70ns variety. I have one board that will do 19MHz reliably using the 55ns chips.

I also use the ST M27C1001-45 EPROM in another board, but it is limited to 16MHz for other reasons. These can be found in 35ns speeds too if you need a bigger faster ROM.

[floobydust]

I started using the Atmel 28C256 EEPROMs years ago. I bought 10 of the 150ns parts back in 2013. Some of which I've reprogrammed hundreds, if not over a thousand times. I've also used them in boards running at over 8MHz without a failure.

I also managed to pickup a tube of 70ns parts which work at 10MHz and over without issue. They do seem to be fairly conservative on their speed rating. Then again, they are on the expensive side compared to of the other chips mentioned in this thread. I'm sticking with them for the time being, as I have ample stock for my current and future needs, plus my Monitor code can write to these insitu without issue (well, provided you program working code into them).

[ttlworks]

Microchip SST39SF040 looks interesting, 5V, available at Mouser:

70ns: DIP, PLCC, TSOP: 1.46€
55ns: PLCC and TSOP.

//SST39VF040 70ns is 3.3V, but not DIP.

[jmthompson]

ttlworks wrote:

Microchip SST39SF040 looks interesting, 5V, available at Mouser:

70ns: DIP, PLCC, TSOP: 1.46€
55ns: PLCC and TSOP.

//SST39VF040 70ns is 3.3V, but not DIP.

My current breadboard '816 SBC build is actually using the SST39VF040. It is available in PLCC-32 which is still pretty easy to work with, and for breadboarding I just use the PLCC-32 programming adapter that came with my TL866 programmer. The only "problem" I have now is trying to find a good use for all that empty ROM space.

[GARTHWILSON]

jmthompson wrote:

The only "problem" I have now is trying to find a good use for all that empty ROM space.

http://wilsonminesco.com/16bitMathTables/

[jmthompson]

GARTHWILSON wrote:

jmthompson wrote:

The only "problem" I have now is trying to find a good use for all that empty ROM space.

http://wilsonminesco.com/16bitMathTables/

Haha, not a bad idea maybe once I get the OS finished and a decent BASIC implementation.

[cbscpe]

As it seems a boot ROM which can keep with the speed of 65 processors is still a subject. In my opinion the ROM should be kept as small as possible and one should actually implement some mass-storage device where the rest of the resident code could be loaded. I had several boot media in mind. Like a floppy controller, a CF-Card (running in 8-bit IDE mode), a TU58 tape (connects via RS-232) or a SD-Card using one of Darys SPI controller (which I still should test the WinCUPL code, once I find time).

In this forum we already had once a discussion using a GAL as ROM replacement as they are much faster, and the challenge was to build a customized hardware interface so the approx 32bytes that a GAL can implement is enough to serve as boot loader. However I was thinking to use a CPLD, like the ATF1504 instead of the GAL. So I'm looking for examples of such boot loaders you have implemented to boot from an external device. The should be as short as possible but still not require a specialised interface. It rather should use a normal interface (SPI, UART, Parallel Port, FDC). Typically this will be some two-step boot process. The "ROM" in the ATF1504 would read some fixed portion from the device (e.g. the first 512bytes) and this will then hold a more elaborate loader.

If you have such a bootloader and are willing to share such bootloaders with me I could check if they would fit in a ATF1504 table.

Using a ATF1504 as a BootROM has several advantages. First it is very fast (10ns). It is available in PLCC (through hole sockets available) and for small SBCs you can use the TQFP-44 package. They are quite low-power and they have can be programmed in-circuit using the JTAG interface. They are still in production and are available for 5V and 3V3 VCC.

Peter


P.S.: TU58 tape is actually a very old cassette tape drive with 256kbyte capacity. It connects via a normal asynchornuous serial interface (RS-232) to the computer and was a very common boot media. It implements a protocol over the serial link which is called RSP, Radial Serial Protocol, which is well documented and very simple. Especially there is a load BOOT sector command which loads the first 512bytes. The protocol actually does not limit the capacity to 256kbytes, in fact it can address 32Mbyte. The tape was actually sector addressable and behaved pretty much like a floppy. Just much slower. However there are TU8 emulators around built on a Arduino that map "tape images" on a FAT SD-Card to the two units available with the TU58 interface. The speed of the serial line could be set to any value, even 500kbps is possible, and would be then much faster than a floppy.

[BigEd]

Can you run a trial synthesis to see how many ROM bytes the AT1504 could serve?

This post has some pointers to related discussions on minimal bootstraps:
viewtopic.php?p=65230#p65230

A 22 byte bootstrap does fit in a modest CPLD:
viewtopic.php?p=10068#p10068

(The bootstrap can be three bytes shorter if the UART is mapped into page zero!)

[cbscpe]

Your Bootstrap loader only uses very few resources of a ATF1504. From the Fitter report you see the percentage of resources used.

Code: Select all

A: LC1	- LC16		14/16(87%)	8/16(50%)	0/16(0%)	62/80(77%)	(14)	0
B: LC17	- LC32		1/16(6%)	8/16(50%)	0/16(0%)	2/80(2%)	(8)	0
C: LC33	- LC48		0/16(0%)	3/16(18%)	0/16(0%)	0/80(0%)	(0)	0
D: LC49	- LC64		0/16(0%)	1/16(6%)	0/16(0%)	0/80(0%)	(0)	0

Total dedicated input used:	1/4 	(25%)
Total I/O pins used		20/32 	(62%)
Total Logic cells used 		15/64 	(23%)
Total Flip-Flop used 		0/64 	(0%)
Total Foldback logic used 	0/64 	(0%)
Total Nodes+FB/MCells 		15/64 	(23%)
Total cascade used 		0
Total input pins 		13
Total output pins 		8
Total Pts 			64
Creating pla file C:\WINCUPL\WINCUPL\NAME.tt3 with 0 inputs 0 outputs, 0 pins 0 nodes and 0 pterms...

----------------  End fitter, Design FITS
$Device PLCC44 fits 
FIT1504 completed in 0.00 seconds

Here the design file I used. E.g. I used the full lower 8 addresses for the table. You could also restrict yourself to the address lines really needed to decode up to 16, 32, 64 bytes. Note that I have not used any optimization and nothing. E.g. you could perhaps even include the Glue Logic for a minimal system. You could even try to include the full address decoding and generate the output enable internally.

Code: Select all

Name     Name ;
PartNo   00 ;
Date     07.12.2019 ;
Revision 01 ;
Designer Engineer ;
Company  privat ;
Assembly None ;
Location  ;
Device   f1504ispplcc44;



PIN			= A0;
PIN			= A1;
PIN			= A2;
PIN			= A3;
PIN			= A4;
PIN			= A5;
PIN			= A6;
PIN			= A7;

PIN			= D0;
PIN			= D1;
PIN			= D2;
PIN			= D3;
PIN			= D4;
PIN			= D5;
PIN			= D6;
PIN			= D7;

PIN		44	= EN;

FIELD	ADDR	= [A7..0];
FIELD	DATA	= [D7..0];

TABLE ADDR => DATA {

'h'E5	=>	'h'A9;
'h'E6	=>	'h'03;
'h'E7	=>	'h'8D;
'h'E8	=>	'h'08;
'h'E9	=>	'h'FE;
'h'EA	=>	'h'A2;
'h'EB	=>	'h'00;
'h'EC	=>	'h'AD;
'h'ED	=>	'h'08;
'h'EE	=>	'h'FE;
'h'EF	=>	'h'6A;
'h'F0	=>	'h'90;
'h'F1	=>	'h'FA;
'h'F2	=>	'h'AD;
'h'F3	=>	'h'09;
'h'F4	=>	'h'FA;
'h'F5	=>	'h'C9;
'h'F6	=>	'h'EA;
'h'F7	=>	'h'F0;
'h'F8	=>	'h'07;
'h'F9	=>	'h'95;
'h'FA	=>	'h'00;
'h'FB	=>	'h'E8;
'h'FC	=>	'h'D0;
'h'FD	=>	'h'EE;
'h'FE	=>	'h'E5;
'h'FF	=>	'h'FF;

}

DATA.OE		= !EN;

[Martin A]

I managed to get a 49 byte bootstrap (z80) to fit into a 22V10.

WinCUPL generated between 9 and 14 Pterms for each data pin, so the output order had to be scrambled a bit to make it fit.

[cbscpe]

That's exactly the limitation, however the difference between a GAL and a CPLD is that the CPLD can borrow PT from neighbor cells (which are either not connected to an PIN or to a PIN which is used as input) and it can produce intermediate terms and route them internally like in the following excerpt

Code: Select all

D0 = (XXL_61
	# (A1 & A2 & A3 & A4));

D1 = ((A0 & A2 & A3 & A1)
	# (A0 & A2 & A3 & A4)
	# XXL_62
	# (A0 & !A2 & A3 & !A4 & !A1));

D2 = ((!A1 & !A2 & A3 & A4)
	# XXL_63
	# (A1 & A2 & A3 & A4));

!D3 = ((!A3 & !A4 & !A2)
	# XXL_64
	# (!A3 & !A4 & !A0));

D4 = XXL_65;

D5 = (XXL_66
	# XXL_67
	# (!A0 & A2 & !A3 & A4));

D6 = XXL_68;

D7 = ((A0 & !A1 & A3 & !A2)
	# XXL_69
	# (!A0 & A1 & A3 & !A4));

IOEN = (!A7 & A8 & A9 & A10 & A11 & A12 & A13 & A14 & A15);

MEMEN = (XXL_70
	# !A13);

RD = (PHI2 & RW);

WR = (!PHI2 & !RW);

XXL_61 = ((A1 & !A2 & !A3 & A4)
	# (A1 & A2 & !A3 & !A4)
	# (!A1 & A2 & A3 & !A4 & !A0)
	# (!A1 & A2 & !A3 & A0)
	# (!A1 & !A2 & A3 & A4));

XXL_62 = ((!A0 & A2 & !A4 & A1)
	# (!A0 & A3 & !A4 & A1)
	# (!A0 & !A2 & A3 & A4 & !A1)
	# (A0 & !A2 & !A3 & A4 & !A1)
	# (!A0 & A2 & !A3 & A4));

XXL_63 = ((!A2 & A3 & A0 & !A1)
	# (A2 & A3 & !A4 & !A0)
	# (!A2 & !A3 & A4 & !A0 & A1)
	# (A2 & !A3 & !A4 & A0 & A1)
	# (A2 & A3 & A4 & A0));

And last but not least, you can in-circuit program the CPLD using a JTAG adapter.

And here is a small example of an all-in-one GLUE logic for an SBC with 128bytes IO and 128kbyte RAM (using a 65SC816 but only decoding A16). It enables the internal ROM table after reset and when writing to an address, in this example 0xFF80, disables the internal table and you are left with a RAM only SBC. IO is placed at 0xFF00..FF7F. Eventually you need to decode the IO addresses to support more devices with an additional IC. But 65xx peripherals have the CS2 which you can map to A4, A5, A6 which would give you three peripheral ICs

Code: Select all

Name		SBC Bootloader ;
PartNo		A ;
Date		07.12.2019 ;
Revision	01 ;
Designer	cbscpe ;
Company		privat ;
Assembly	none ;
Location	CH ;
Device		f1504ispplcc44 ;

PROPERTY ATMEL {preassign = KEEP};

PIN			= A0;
PIN			= A1;
PIN			= A2;
PIN			= A3;
PIN			= A4;
PIN			= A5;
PIN			= A6;
PIN			= A7;
PIN			= A8;
PIN			= A9;
PIN			= A10;
PIN			= A11;
PIN			= A12;
PIN			= A13;
PIN			= A14;
PIN			= A15;
PIN			= A16;
/*
PIN			= A16;
PIN			= A17;
PIN			= A18;
PINNODE		= A19;
PINNODE		= A20;
PINNODE		= A21;
PINNODE		= A22;
PINNODE		= A23;
*/
PIN			= PHI2;
PIN			= RW;
PIN			= RD;
PIN			= WR;
PIN			= RESET;
PIN			= IOEN;
PIN			= MEMEN;
PINNODE		= BOOT;


PIN			= D0;
PIN			= D1;
PIN			= D2;
PIN			= D3;
PIN			= D4;
PIN			= D5;
PIN			= D6;
PIN			= D7;

FIELD	DATA = [D7..0];
FIELD   ADDR = [A16..0];

TABLE [A4..0] => DATA {

'h'E5	=>	'h'A9;
'h'E6	=>	'h'03;
'h'E7	=>	'h'8D;
'h'E8	=>	'h'08;
'h'E9	=>	'h'FE;
'h'EA	=>	'h'A2;
'h'EB	=>	'h'00;
'h'EC	=>	'h'AD;
'h'ED	=>	'h'08;
'h'EE	=>	'h'FE;
'h'EF	=>	'h'6A;
'h'F0	=>	'h'90;
'h'F1	=>	'h'FA;
'h'F2	=>	'h'AD;
'h'F3	=>	'h'09;
'h'F4	=>	'h'FA;
'h'F5	=>	'h'C9;
'h'F6	=>	'h'EA;
'h'F7	=>	'h'F0;
'h'F8	=>	'h'07;
'h'F9	=>	'h'95;
'h'FA	=>	'h'00;
'h'FB	=>	'h'E8;
'h'FC	=>	'h'D0;
'h'FD	=>	'h'EE;
'h'FE	=>	'h'E5;
'h'FF	=>	'h'FF;

}

A16.l			=  D0.io;
A16.le			= !PHI2;

/*
[A23..16].l		=  DATA.io;
[A23..16].le	= !PHI2;
*/

DATA.oe			=  PHI2 &  RW  &  ADDR:['h'FFE0..FFFF] & BOOT;

RD				=  PHI2 &  RW;
WR				= !PHI2 & !RW;

BOOT.ap			=  RESET;
BOOT.ar			=  ADDR:['h'FF80] & PHI2 & !RW;
BOOT.ck			= 'b'0;
BOOT.d			= 'b'0;

IOEN			=  ADDR:['h'FF00..FF7F];
MEMEN			=  ADDR:['h'0000..EFFF]
				#  ADDR:['h'10000..1FFFF]
				#  ADDR:['h'FF80..FFFF] & !RW
				#  ADDR:['h'FF80..FFFF] &  RW  & !BOOT;
				
				
			
				

Peter