27C400 EPROM emulators (beta) issue D technical discussion

General discussions or ideas about hardware.
Squirrel61
Posts: 15
Joined: Wed Dec 18, 2019 5:22 pm

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by Squirrel61 »

The redscreening ROM image is definitely at fault, because it also redscreens in UAE. I have flashed another working ROM in the same slot and that is working.

Btw. the rom was read from a working rom, using an EPROM programmer but still it has a checksum error. That means when I dump a rom from a real (EP)ROM chip, I should verify it before trying to use it ;)
User avatar
PaulJ
Posts: 1568
Joined: Sun Apr 08, 2018 1:14 am
Location: USA

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by PaulJ »

cmorley wrote: Mon Feb 03, 2020 2:05 pm What revision Amiga did you put it in. If it is a rev 3 or rev 5 you need to blob the /JEDEC solder jumper to change the pinout.
Hi Chris, what does the /JEDEC jumper do..?? Change the pinout??? Chris could you elaborate for those of us not using an Amiga.

A17 on the pinout of the chip is shown as pin 1. Yet you have a A17, A18, A19 pad on the top. Which is the A17 connection.
cn.jpg
cn.jpg (22.33 KiB) Viewed 5940 times

I want A17, A18, A19 to be low. Enabling them and setting the pull-up to on makes them a high. If I don't turn the pull-up on does that force a low? What does enable do in this context?

>option menu
A17 A18 A19
pull-up y y y
enable y n n
ROM size 27C400 512KB
intial ROM 0
autosave initial y
ROM switch pullup y
SP pin mode 3
USB FACTORY

If I have the rom size set as shown above is this setting the rom emulator to use the first of 4 512k blocks. If the area of flash used is controlled via initial ROM and the reset step it can I just ignore A17, A18, A19 since there handled internal to the emulator. Are the Pads there when using 2048 kb size?

In conclusion I tried the second Eprom Emulator and it works as the other one so I'm assuming both are good and its my failing because of the way I'm programming it. Always programs and verifies.

Any pointers appreciated Chris. Thanks
cmorley
Posts: 291
Joined: Tue May 28, 2019 5:46 pm

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by cmorley »

/JEDEC switches to the Commodore Amiga 500 rev3/5 pinout. Solder blob = C'dore, open = JEDEC pinout.

A17 is connected to the pad and the pin. A 27C200 has NC on pin 1 so I broke it out to the pad as well. The pads are there to connect to another module or the extra address lines for 27C800 and 27C160.

Enables is to enable the STM32 driving the address pin. You need that for any undriven address line so on for A18&19 and off for A17 (27C400). Pull ups are required or the pin will float when not driven low by the STM32 (wired OR). Don't set the pull up on pins driven by 5v i.e. A17 (the STM datasheet says this is bad - presumably shorts 5v to 3v3 through the upper output mosfet... eventually it will burn out that mosfet I imagine).

Turn autosave off so it always powers up on the image you intend (enable it when you're happy it is all working).

Run the preset wizard and select 27C400. It will set the pull ups and enables etc correctly for a 27C400.

You need the pull up on ROM switch if you are using a mechanical switch pulling R to ground. If you connect it to a 5v /RST line in the machine then disable the pull up on ROM switch. (Same reason STM datasheet says don't shove 5v up a pin with PU enabled)
User avatar
PaulJ
Posts: 1568
Joined: Sun Apr 08, 2018 1:14 am
Location: USA

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by PaulJ »

@cmorley , got it working on the Mega4. Earlier today I got it mapped into $e00000 without attempting to use it as a bootROM but was able to verify programmed code showed up correctly. But when I attempted to boot from it (adding in 0-7 decode) it would crash and halt. So the only thing i could conceive that screwed it up was the 0-7 decode stolen from U9 or U10 pin 20 was too delayed after the LightingST processed it into its Chip select. So I moved the board cs signal from U9 or U10 to pin two of U12 which saves one gate delay and that caused it to work.

IMG_2440 copy.jpg
IMG_2440 copy.jpg (530.27 KiB) Viewed 5910 times
cmorley
Posts: 291
Joined: Tue May 28, 2019 5:46 pm

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by cmorley »

Thumbs up.

I don't know the hardware you are using so can't really comment on using it as a boot ROM. You should be able to though. How big are each ROM?

If you can get a /CS and /OE which activate for both ROMs, set the module to 27C800 and hook up A18 on the module to the computer (on an appropriate address line) so it selects the correct bank - that should work. Assuming you need 2x 256Kx16 ROMs emulated then you could switch between 2 images.
User avatar
PaulJ
Posts: 1568
Joined: Sun Apr 08, 2018 1:14 am
Location: USA

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by PaulJ »

@cmorley , I have a few questions. Since my 16bit boot rom is 256k I am attempting to setup 8 bootroms I access. But the second one I try is TPS 1.04 which is 192512 bytes in a 256k rom. So I need to do a partial burn.

Since you do not echo operator input I have added it in []'s.

Command: program 27C200 (256KB)
Partial? y/n [y]
Slot? 0-7 [1]
Image size? [0x]digits[K|M] [2F000]
Offset into ROM? [0x]digits[K|M] [0x0]
Byte swap? y/n [y]
Load word mode? n=normal, h=hi, l=lo [n]
Erase, done
Address=040000,040001
Send binary
2/2
Took 0.000s

OK

unrecognised command
h for help

1. What is "Load word mode? n=normal, h=hi, l=lo" I've already said swap bytes in the binary image?
2. Why "Address=040000,040001" Although the 0x40000 looks like a good start address what is "040001"?
3. I aways get "unrecognized command"
4. If I don't use K|M I assume I'm entering bytes? Is that correct?

Thanks Chris...
cmorley
Posts: 291
Joined: Tue May 28, 2019 5:46 pm

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by cmorley »

PaulJ wrote: Sat Feb 08, 2020 7:05 pm Image size? [0x]digits[K|M] [2F000]

1. What is "Load word mode? n=normal, h=hi, l=lo" I've already said swap bytes in the binary image?
2. Why "Address=040000,040001" Although the 0x40000 looks like a good start address what is "040001"?
3. I aways get "unrecognized command"
4. If I don't use K|M I assume I'm entering bytes? Is that correct?

Thanks Chris...
You need to preceed hex with 0x. strtoul() will see 2f000 as 2. K & M are optional.

Load word is for splitting a 32bit image. Load hi/lo word from a 32 bit file.

Address shows the range so you are programming 040000-040001 (2 bytes).

Unrecognised command comes because it expected 2 bytes of data and you sent it more. The menu eats all input after it sees a byte it doesn't like.

You can also use truncate in linux to pad a file to the nearest 2 power & send a full image. Or srec_cat.
User avatar
PaulJ
Posts: 1568
Joined: Sun Apr 08, 2018 1:14 am
Location: USA

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by PaulJ »

Thanks @cmorley , that helps and I was able to program KAOS142 into ROM 3 using partial programing, so I have TOS2.06, TOS1.04, DiagROM, and KAOS142 in the first four ROM slots. Now I have to find 4 more bootroms to populate the last four slots. @exxos , your decode signal tapped off the IDE board works flawlessly with EPROM emulator. The LightningST decode is to slow for the eprom emulator.

I was able to program new slots without the partial burn command by using the main menu program command and send the shorter file and after it hung pull the USB cable and reinsert. Not the best practice I'm sure but it did work also. Maybe a timeout would be in order.
cmorley
Posts: 291
Joined: Tue May 28, 2019 5:46 pm

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by cmorley »

PaulJ wrote: Sat Feb 08, 2020 8:07 pm The LightningST decode is to slow for the eprom emulator.
This is surprising. The Emu should be a lot faster than an EPROM ~90ns equivalent worst case with the 70ns FLASH chips and faster still with the 55ns FLASH. So I wouldn't have thought it was an access time thing - some other timing thing.

I have had problems with other projects in the past where the hardware being too fast is causing a problem. Glitching on control signals causing problems only with new faster kit...

I wonder what is going on in this case?
czietz
Posts: 547
Joined: Sun Jan 14, 2018 1:02 pm

Re: 27C400 EPROM emulators (beta) issue D technical discussion

Post by czietz »

PaulJ wrote: Sat Feb 08, 2020 8:07 pm The LightningST decode is to slow for the eprom emulator.
To be honest, I rather doubt that. When just passing ROM2 through (for booting or for access to the 0xFC0000 - 0xFEFFFF address range), the Lightning ST adds about 7 ns delay. When decoding a ROM access by itself (to 0xE00000 - 0xE7FFFF), the Lightning ST chip select output becomes low within 8 ns of the falling edge on /AS. These delays are small enough even for slow EPROMs.
Post Reply

Return to “HARDWARE DISCUSSIONS”