Smallest parallel EPPROM available in 2023

[jfoucher]

Hi, I'm looking for a very small parallel EEPROM that is available to buy right now. 256 bytes would be sufficient. Do they exist? i assume they existed in the past, but can they still be found now, and if so where should I start looking? Mouser et all do not have any parallel EEPROMS with a capacity below 64kbit.

Thanks.

[floobydust]

The smallest EEPROM that I can recall is the Atmel AT28C16, which is obsolete. It's a 2KB x 8-bit parallel part in a 24-pin package. Perhaps eBay, UTsource or some others might have some NOS or pulls.

[Proxy]

can i ask for what you want to have such a small ROM for?
wouldn't it be enough to use a common 8k (or really any sized) ROM and just ground the unused address lines?
it's functionally the same and saves you the trouble of finding some exotic/expensive part. and if you're after saving PCB space, consider some non-DIP ROMs like the SST39SF0x0 series, which come in a 32-pin PLCC package that (including the socket) is around half the area of the DIP variant but is otherwise completely identical.

this is basically what i did in all my SBCs, i've always used 512kB Flash chips and just grounded the upper address bits i don't need. and for space reasons i've used the PLCC version on my current 65816 SBC.

hmm, though if you want you could use a PLD/CPLD to implement a tiny ROM in logic. though that adds the complexity of having to program it...

[plasmo]

You can create 64-byte fast ROM with CPLD without sacrificing too many logic cells for other CPLD functions.
Bill

[jfoucher]

I have recently managed to read data from a CompactFlash card, and I wanted to try using a very small boot rom just for the challenge I guess, to see how low I go go and still be able to load everything into RAM from the CF card. I managed to get it down to about 200 bytes, which I thought was nice.
I was asking mainly out of curiosity to be honest.

The CPLD is a nice idea, but I guess 64 bytes will not be quite enough to put everything I need to read the CF card. For the moment I am playing around with a 28C64 which is fine. The idea I had was to make the ROM as small as possible so that I can put on more RAM, but I just change the memory mapping to address the RAM instead of the ROM in certain ranges, and then the ROM size does not matter at all.

Out of curiosity again, does anyone have reference to code for putting ROM data on a CPLD ? (I am used to WinCUPL to program GAL chips) And which suitable CPLDs have general availability ?

Thanks!

[plasmo]

I believe you can read CF into RAM with 32 bytes of ROM, you definitely can read CF into RAM with 64-byte ROM plus additional functions since I’ve done it with CRC65. ROM is just a lookup table, so I use verilog table to create a ROM. This is using Quartus tool chain.
Bill

[kernelthread]

I got hold of some 28C16s on ebay in 2021, from here:
https://www.ebay.co.uk/itm/192622840470 ... 2761890582
It looks like they are still available, but the price has increased considerably since I bought them.
A 22V10 would probably make a good small ROM - it has lots of product terms. But I don't reckon you'll get 200 bytes into one; 64 bytes maybe.

[jfoucher]

plasmo wrote:

I believe you can read CF into RAM with 32 bytes of ROM

Haha, ok, challenge accepted! I'll give that a try first of all and let you know how it goes!

kernelthread wrote:

A 22V10 would probably make a good small ROM - it has lots of product terms.

Oh interesting on the 22V10, I have quite a few of those. I'll see if I can work something out with wincupl, thanks!

plasmo wrote:

ROM is just a lookup table, so I use verilog table to create a ROM

If i'm trying that with a 22V10 then AFAIK only WinCupl will work (more than happy to be wrong on that front). I'll check if and how it handles lookup tables.

[kernelthread]

Here's a bit of C code I wrote a while back which transforms a binary file into a CUPL statement which creates a ROM.

bin2cupl.c

(1.66 KiB) Downloaded 62 times

You use it like this:
bin2cupl rom_contents.bin >data.inc

Then process the following file with WinCUPL which includes the file generated above:

ROM22V10.TXT

(950 Bytes) Downloaded 62 times

[jfoucher]

kernelthread wrote:

Here's a bit of C code I wrote a while back which transforms a binary file into a CUPL statement which creates a ROM.

Oh very nice, thank you!

[plasmo]

jfoucher wrote:

plasmo wrote:

I believe you can read CF into RAM with 32 bytes of ROM

Haha, ok, challenge accepted! I'll give that a try first of all and let you know how it goes!

Now I don't think 32-byte ROM to copy CF to RAM is likely for 6502. One of the reason is because 6 bytes at top of ROM are needed for NMI, reset, interrupt vectors, so there is only 26 bytes left for code. For Z80 it is possible to copy CF to RAM and execute in 26 bytes, but Z80 has more advanced instruction set. For your reference, this is Z80ALL's 26-byte bootstrap code copying 256 bytes from CF master boot record to locations 0xb000 and jump into it.
Bill
--------------------------------

Code: Select all

CFdata   	equ 010h    	;CF data register
CFstat   	equ 017h       	;CF status/command reg

	ld hl,0b000h	;bootstrap code starts from 0xb000
readbsy:
	in a,(CFstat)	; read CF status 
	rla		; check busy bit
	jr c,readbsy
	ld c,CFdata	; reg C points to CF data reg
	ld a,20h		; read sector command
	out (CFstat),a	; issue the read sector command
chkdrq:
	in a,(CFstat)	; check data request bit set before read CF data
	and 8		; bit 3 is DRQ, wait for it to set
	jr z,chkdrq
	inir		;z80 read 256 bytes
	jp 0b000h

[jfoucher]

So this is as far as I managed to get:

Code: Select all

reset:
cf_init:
    jsr cf_wait
    lda #$E0
    sta CF_ADDRESS + 6
    lda #$1
    sta CF_ADDRESS + 1
    inc
    sta io_buffer_ptr + 1   ; store 2 in high byte of pointer
    stz io_buffer_ptr       ; store 0 in low byte of pointer
    lda #$EF
    sta CF_ADDRESS + 7
    jsr cf_wait
set_lba:
    ; start load at sector 0
    stz CF_ADDRESS + 3
    stz CF_ADDRESS + 4
    stz CF_ADDRESS + 5
    lda #$E0
    sta CF_ADDRESS + 6
read_sectors:
    ; Load enough sectors to fill the RAM
    lda #(((RAM_END-CODE_START)/$200)-1) 
    sta CF_ADDRESS + 2
    lda #CF_READ_SECTOR_COMMAND
    sta CF_ADDRESS + 7
cf_read:
    lda CF_ADDRESS + 7  
    bmi cf_read         ; wait if not ready
    and #$08
    beq start           ; nothing left to read
    lda CF_ADDRESS
    sta (io_buffer_ptr)
    inc io_buffer_ptr
    bne cf_read
    inc io_buffer_ptr + 1
    bra cf_read
start:
    jmp (CODE_START)

cf_wait: 
    lda CF_ADDRESS + 7
    bmi cf_wait             ; wait FOR RDY to become unset
    rts

I had many calls to cf_wait, most of which I could safely remove. Not the ones after setting a CF command though...
I am now at 81 bytes, not counting 6 bytes for the ROM vectors.

Let me know if I should start a new thread in Programming, but if anyone has ideas to make this code smaller, I'm all ears.

[floobydust]

Well, as I like say, you can't argue with success

A bit of feedback:

- As you already set the drive_head register for drive 0 and the upper 4 LBA address bits as zero, you shouldn't have to set them again (my assumption below)
- As this is pointed to by the reset vector, the stack pointer is not set by default (perhaps it doesn't matter)
- You can save a byte using a loop to fill the rest of the LBA number in to the 3 registers

Here's what I copy/pasted from my BIOS, with some changes, that should load a block to memory. It's a bit different, is 76 bytes, but untested!

Code: Select all

;
;Reset Vector points to here!
; Assume you have a working IDE controller ;-)
; Just set it up to load LBA zero to memory and jump to it.
; - this assumes the single 512-byte contains rest of the boot loader, which can be more flexible 
;
; NOTE: constants and variable are not shown here!
; - you need to define the IDE registers, the BIOS_XFER pointer in page zero and the load address!
;
;Init the IDE controller
; First, set the stack pointer, then setup the IDE controller to read a block into memory
;
IDE_INIT
                LDX     #$FF            ;Get $FF
                TXS                     ;Set Stack pointer
;
                JSR     TST_IDE_BUSY    ;Check/wait if IDE is still busy after HW Reset (6)
;
; Setup memory pointers first:
                LDA     #<LOAD_ADDR     ;Get Load address
                LDY     #>LOAD_ADDR     ; A/Y = Low/High
                STA     BIOS_XFERL      ;Set Page Zero pointer
                STY     BIOS_XFERH      ; Load/high
;
;IDE Setup
; First, set 8-bit mode, then setup for LBA zero to start loading from.
; - also set for a single block transfer (a partition record)
; - then send the read block command
;
                LDX     #$03            ;Set Index count for 3 (2)
PARM_XFER_LP
                STZ     IDE_SCT_NUM-1,X ;Zero IDE lower LBA registers (5)
                DEX                     ;Decrement count (2)
                BNE     PARM_XFER_LP    ;Loop back till done (2/3)
;
                INX                     ;Increment X to $01
                STX     IDE_SCT_CNT     ;Send to IDE for 1 block xfer (4)
;
                STX     IDE_FEATURE     ;Send to IDE controller (4)
                LDA     #%11100000      ;Get Drive 0, LBA. mode, etc. (2)
                STA     IDE_DRV_HEAD    ;Send to IDE controller (4)
                LDA     #$EF            ;Get Set Features Command (2)
                JSR     SEND_IDE_CMD    ;Send to IDE and wait till accepted
;
                LDA     #$20            ;Get LBA Read command
                JSR     SEND_IDE_CMD    ;Send to IDE and wait till accepted
;
; - Check for Data Request (DRQ), as the Read LBA operation is the main function
;   of the ISR, which will handle the data transfer from the IDE controller to store the
;   data into memory. This ISR will handle single and multiple block transfers.
;
LBA_XFER        LDA     IDE_STATUS      ;Get Status (clears IRQ) (4)
                AND     #%00001000      ;Check for DRQ (2)
                BEQ     IDE_RD_DONE     ;If not active, done, exit (2/3)
;
IDE_RD_RBLK
                LDA     IDE_DATA        ;Read a byte from IDE (4)
                STA     (BIOS_XFERL)    ;Store low byte (5)
                INC     BIOS_XFERL      ;Increment pointers (5)
                BNE     IDE_RD_RBLK     ; (2/3)
                INC     BIOS_XFERH      ; (5)
                BRA     LBA_XFER        ;Loop back until done
;
IDE_RD_DONE
                JMP     (LOAD_ADDR)     ;Jump to code to start
;
SEND_IDE_CMD
                STA     IDE_COMMAND     ;Send command to IDE
;
TST_IDE_BUSY
;
;Test for IDE Controller Busy
; This routine loops on the Busy flag. If the IDE Controller is busy, no other
; status register flags are valid and no commands can be sent to the IDE Controller.
; Hence, this routine is key to determine if the IDE Controller is available to
; accept a command. Bit 7 is the Busy Bit. The 65C02 will set the "n" flag
; if Bit 7 is active, else clear it.
;
                LDA     IDE_ALT_STATUS  ;Get IDE Alternate Status register (4)
                BMI     TST_IDE_BUSY    ;Loop until BUSY bit is clear (2/3)
                RTS                     ;Return to Caller (6)
;

If you ditch the stack setup, that saves 3 bytes, if you just zero the one page zero pointer, that saves 2 more bytes. Also, you would add 2 bytes by loading more than 1 block.

Hope this helps...

[plasmo]

Yes, start a new thread about small bootstrap code or state machine for load & run CF data. I can share how CRC65 dual boot from CF or serial port in 64 bytes; and how Z280RC boot from CF using hardwired state machine.
Bill

[jfoucher]

Here is the new post: viewtopic.php?f=2&t=7559