Assistance with assembly code for 5160 ROM

[alejack12001]

No success with loading the ROM file received from 640KB. I flushed the D27C256 chips that I have with UV light for an hour. Then, using my GQ 4x4 powered by its supply, I loaded the ROM. The write cycle loaded; however, the verify error occurred again, this time with a different address: 0x007D77. The device was 0xFE, and buffer = 0xFF.

The GQ 4x4 programmer reads the file sent from 640KB as a ROM, not a binary. Under the ROM setting, are there any special adjustments for the ROM setting concerning burn/write speed, file offset, etc. Mine reads all normal. The typical setting for me is usually BINARY with offset set to 0x0000. I did use a power supply.

I need to know if there are any settings needed to get this ROM on the chip without errors. I have some added chips on order; however, I think they may be used.

 

[alejack12001]

I have decided to give up on loading this ROM onto the D27C256 chips. I will retry once I figure out the assembly code for the GLaBIOS and the floppy check commands. I am grateful to 640KB, one of the developers of GLaBIOS, for letting me have the ROM code he downloaded from his system. There is an issue that occurs when the ROM is loaded onto the 27256 chip.

 

[Ruud]

I cannot remember mentioning in this thread but I created a "socket converter" that enables me to use 32-pin 29F010 FlashRAMs. The advantage: I can test other or newly created ROMs and once things work fine, I program a real EPROM. I created this converter by soldering a 32-pin Textool socket on top of an obsolete 28-pin EPROM. Of course after removing the glass and the die.
Almost forgot: there is the 27SF512 FlashRAM as well. No converter needed and the GQ will have no trouble with it. I know bc I had one and used it for programming the SF (until it broke one day).

 

[modem7]

The GQ 4x4 programmer reads the file sent from 640KB as a ROM, not a binary.

I opened the .ROM file from post #71. I see no header, nor compression. etc. It looks like a raw binary file to me.

( I have seen some people use .ROM if the binary file is from/to a ROM. Some people, like me, use the .BIN file extension for all binary files. )

Under the ROM setting, are there any special adjustments for the ROM setting concerning burn/write speed, file offset, etc.

There is nothing special to do. It should be a case of choosing the make-model of EPROM you have, and based on that, the software will set up the required programming timings.

Certain settings, like 'file offset', do not affect the ability to program-then-verify.

I flushed the D27C256 chips that I have with UV light for an hour.

I am seeing some information online that suggests that EPROM's can be damaged by too much UV exposure.

I have some added chips on order; however, I think they may be used.

Let's see how those ones go.

 

[alejack12001]

I cannot remember mentioning in this thread but I created a "socket converter" that enables me to use 32-pin 29F010 FlashRAMs. The advantage: I can test other or newly created ROMs and once things work fine, I program a real EPROM. I created this converter by soldering a 32-pin Textool socket on top of an obsolete 28-pin EPROM. Of course after removing the glass and the die.
Almost forgot: there is the 27SF512 FlashRAM as well. No converter needed and the GQ will have no trouble with it. I know bc I had one and used it for programming the SF (until it broke one day).

This flash ROM you acquired is similar to one that I acquired called OneROM (https://onerom.org/). This might be an idea to load the ROM into my acquired 28-pin model. Worth a try. Thanks for the suggestion.

 

[alejack12001]

I opened the .ROM file from post #71. I see no header, nor compression. etc. It looks like a raw binary file to me.

( I have seen some people use .ROM if the binary file is from/to a ROM. Some people, like me, use the .BIN file extension for all binary files. )


There is nothing special to do. It should be a case of choosing the make-model of EPROM you have, and based on that, the software will set up the required programming timings.

Certain settings, like 'file offset', do not affect the ability to program-then-verify.


I am seeing some information online that suggests that EPROM's can be damaged by too much UV exposure.


Let's see how those ones go.

I, too, looked at the ROM file and found what you found: no header and no compression. Early on, I changed the ROM to .BIN and encountered the first error, which was posted in post 76. The comments suggested a defective UV chip, so I flashed another D27C256 chip using the ROM setting. The error appeared near the end of the file, as shown in post 81. Why the verify flagged that location is a mystery to me.

Actually, you're probably right; an hour is too long under UV light for a single chip. Maybe 15 minutes would be better.

I, too, looked at the code for the GLaBIOS; I have to tip my hat to the level of detail in the assembly code and the comments included within it.

I plan to take Ruud's suggestion about using the flash ROM chip and loading the ROM file. I'll see if I get an error from that platform.

 

[alejack12001]

Well, good news. I was able to load the ROM received from 640KB onto a new 27C256 chip by converting the ROM to BIN. So, my older D27C256 chips were the problem, with my exposing them to too much UV light to erase them. These new chips were made in Korea. The relabeling of the file from ROM to BIN loaded fine and verified without any errors.

I have one inquiry for 640KB regarding the quad controller board from Tex Elec. In post 71, your message to me was to turn off SW1 position 7. Now that I have the GLaBIOS without floppy check routine loaded onto the ROM, should this switch remain off? The reason I ask is that I think I have to set the quad controller to recognize the 360-KB floppy drive and 1.44-MB GoTek floppy drive emulator. In the configuration procedure, the user selects the drives from the on-board ROM of the quad controller and writes them to the card. My machine has been off for a while, and I thought the process needed to be checked or initiated again.