X68000 IPL replacement ROM

[eidis]

 Ladies and Gentlemen,

Most of you have probably seen the two empty ROM sockets in the twin tower X68000 systems. If not mistaken, they can be equipped with a different IPL (BIOS). We could hack the original IPL or make our own with integrated SxSI driver and a custom written program which allowed us to transfer XDF floppy images through serial cable from PC and write them to physical media on the X68000.

Is there any guru who could help or guide us in fulfilling this very ambitious project ?

Keep the scene alive !
Eidis

[lydux]

Yep ! Already done this on an ACE and CZ600.

My problems was that the SRAM quickly goes full because of many IOCS patchs (38400bps SCC, LCD monitors timing fix, etc...), SASI driver and various development stuffs. I also had in mind to change the CPU by something more advanced (MC68020 for instance) and wanted to use the FPU emulator from NetBSD. So I managed to fully disassemble the IPL 1.3, and make it recompilable with my toolchain.

Actually, this bios is not suitable for you but I already have the original source code with some parts converted to C. So ready for customizing, it will not be too hard integrating something within it.


But first Eidis, is it a requirement or just an idea in your mind ? I mean, originally this bios mod was not necessary intend to be used with Human68K or gaming purposes (but should work), and IOCS system calls are numerous, I can't test them all. So it needs heavy beta testing (basically using the computer normally).
Do you actually own the necessary tools to burn and erase 27C512 EPROMs ?



Screenshot taken from a modified xkeropi that allow me to simulate a wrong memory board addon configuration. Don't be fooled by the "F9" switch.x key, it's actually not implemented (but planned).

[SQZ]

Hi!

What a great idea! 

Maybe this would help to diagnose and test some x68000 with unkown faults. I'll explain:

After months reading this great forum, I am desperate with a x68k ACE I am trying to "repair" (several months of trial-error attempts), or at least, to see anything on screen different from the "insert disk" or "error, reboot" screens. As I can not boot from floppies (I'll explain this later) I have been trying to boot from a SCSI HD, but as it is a SASI machine I need to install SxSI into SRAM. I can't because I can't boot from floppy and the serial connection via Null-modem does not work (I don't get the debugger in the terminal, computer just hangs with black screen).

I think A replacement of IPL ROM would be great to help with this. With an "injected" SxSI driver or testing tools (RAM, buses, etc) it would be easier to diagnose.

Symptoms of the ACE: With no disks in the floppy drives: normal "insert disk" screen. With bootable disk in: "error, reboot" screen, ALWAYS (well, some times it ejects the disk, but only a few).

Before you give the usual advices, I'll enumerate all I've done over the last months with this ACE (It is my only x68000, have no other to try, I bought it faulty):

- PSU: Fully recapped.
- Floppy drives: fully recapped, and tested (with DIY cable) in PC, both drives work perfectly. Read and write 1,2mb  HD disk without problems.
- Battery: desoldered old battery and replaced with Coin type batt.
- Resoldered 1 broken track near the battery in the lower board.
- After that, Checked EVERY track with a multimeter in the lower board. Everything OK.
- Tested with original and different floppy data cable.
- Made ATX PSU mod
- Replaced 68000 CPU on the mainboard.
- Reseated Riser expansion board
- Reseated every other cable or connector.
- Recapped lower board.
- Recapped mainboard
- Sram resets (several times, several days)
- Tried to boot with 10 differnet boot disks (human, games, etc..) written by me or by other friends.
- Burned a copy of the original IPL ROMs to a pair of 27c512.
- Made 2 different null-modem cables (with info I got here and in other jp sites. I checked the cabling several times and with different PC computers), tried to get the builtin debugger to work over serial, did not work. Holding OPT2 when power-on ends in a black screen and nothing is sent over the rs232 port. Tried with every speed (bps) available, every combination of bits, parity, etc. Days and hours spent on this without results. I thought, maybe as I read here (thaks to lydux), I could fill the SRAM with the SxSI driver at least to try to boot from an HD to see if it works and discard some problems (as the floppy controller not working well, etc..), but it doesn't want to work... 

Nothing changed. At every attempt, I get the same results.

You could imagine my desperation... I thought about IPL ROM replacement, but my knowledge is very very far of that, and let it go, keeping the poor x68k in the closet.

Do you think this IPL replacement project would help with this situations?
I have all the tools needed for ROM replacement. EPROM burner, some EPROMS and EEPROMS (27c512 type and others), etc.

Thank you in advance!!!

Great forum, impressive members here! 

[lydux]

Hi SQZ, and welcome to NFG board !

Thanks for your detailed check list. I'm strongly suspecting a bad (corroded) trace or cable around IOSC chip on I/O board. This often happen on ACE models when battery has leaked. I know : you already checked this part, but I recommand you to check carefully again, especially probing for trace between IOSC pins and the connector. The IDC connector itself might be corroded ! (I've seen this...)
This area is responsible of transferring datas between CPU, floppy controller, and SCC (serial controller).

You're right : having something other than an on-screen diagnostic is a great idea ! I myself had used of it :

Some month ago, I identify the issue in a CZ600 using a bios approach. Its sprite controller oscillator were bad (the ~69Mhz one), causing him to not answer during bios initialization, and so crash the whole machine leaving a black screen. Basically, at very first this bios initialize the SCC to a known state and install a program code tracer redirecting the output to the RS232 line, then execute the main bios. When the crash occurs, it outputs the exact address in rom causing the crash. By a bit of disassembly of the provided bios, this show me a sprite controller access.

In the same idea, I'm currently thinking of some kind of POST message in the serial line...
However, in your case the SCC might not be totally accessible, so we have to find a second way not involving the I/O board. It reminds me an old thread here where a guy wondering about a led based error code, and a RAMDISK driver which make one of front led blink on access. I will investigate this way.


Off topic, one last thing :

- Battery: desoldered old battery and replaced with Coin type batt.

You shoudn't do this ! Coin type battery aren't meant to be charged which is a normal behavior on ACE models. If you really want this, remove the charging circuitry !

[SQZ]

Hi SQZ, and welcome to NFG board !

Hi, and thank you for your fast response!

Thanks for your detailed check list. I'm strongly suspecting a bad (corroded) trace or cable around IOSC chip on I/O board. This often happen on ACE models when battery has leaked. I know : you already checked this part, but I recommand you to check carefully again, especially probing for trace between IOSC pins and the connector. The IDC connector itself might be corroded ! (I've seen this...)
This area is responsible of transferring datas between CPU, floppy controller, and SCC (serial controller).

Yes, I thought the same when I was thinking again and again about all the symptoms. Then I centered my attention on the I/O board (the lower board) and already checked what you said. I did it about 6 times (yes, I counted it... the desperation, you know..) in diffferent moments of this year...  I traced all the pins from the connector to the rest of the board and probing with my multimeter...results: Every pin of the connector have perfect connection with the pins of the involved chips (IOSC chip inlcuded). Every pin. I checked that, altough the connector was not corroded, because I had nothing to lose. In fact I had the hope of not hearing the "beep" when I was checking a pin...  but.. nope.

Maybe the cable that connect the mainboard with the I/O board worth a check... but I have no hope on it...

Off topic, one last thing :

- Battery: desoldered old battery and replaced with Coin type batt.

You shoudn't do this ! Coin type battery aren't meant to be charged which is a normal behavior on ACE models. If you really want this, remove the charging circuitry !

No problemo on that... I used a diode

Thank you again!!!

What things do you think would worth to be included in a custom ROM then?

(Ah, and sorry for my english, it is not as good as I would want... )


EDIT:

You're right : having something other than an on-screen diagnostic is a great idea

But I did not remember to have said that... (maybe my bad english...) in fact (in my case, with no response from rs232 port) an on-screen diagnostic would be really great! The display out works as I can see the "inser disk" screen and the error screen (in japanese, of course).

[H68k]

This is a fantastic idea! it would be great having a ROM set with hardware diagnostic/trouble shooting utilities built in (like a more modern day PC bios)

Would it be possible to produce a ROM set with Human68k built in? (I'm thinking about an OS on a chip it would boot off, if it could not find any bootable disks)

also could you make a ROM set that bypasses the floppy drive checks? and searches for a bootable SCSI/SASI drive instead. This could help out people with the "blank screen and hang on boot" problem because of screwy or dead floppy drives.

[costa]

People,

This ROM ideia is soo great!

All the ideias coming from using a replacement ROM are fantastic, very useful and I can already say "how could we live without this" ?

Bios to bypass floppy verification, to debug failures, drivers, utilities and maybe the entire SO in ROM... what great ideais.

I have eprom writer as well, and definitely would be one of the first trying that.
I might find some ways to help as well...

[eidis]

 Hi Lydux !

I read your first post and was completely mesmerized. You are always 10 steps ahead of everyone.

But first Eidis, is it a requirement or just an idea in your mind ? I mean, originally this bios mod was not necessary intend to be used with Human68K or gaming purposes (but should work), and IOCS system calls are numerous, I can't test them all. So it needs heavy beta testing (basically using the computer normally).
Do you actually own the necessary tools to burn and erase 27C512 EPROMs ?

Due to chronic addiction with old hardware I have two EPROM burners and 27C512 chips too. The custom IPL would effectively solve the problem of transferring XDF files to and from physical media so it is a requirement and I would be more than happy to beta test the ROM.

Here is what I think should be included in the custom IPL and why.

1) Integrated tool which can receive/send XDF files through serial port and write them to physical media. (most new users often complain about building a dedicated PC and gambling with 5.25" floppy drives until they find one that works)
2) Integrated SxSI driver, for obvious reasons

There are many other things which could be included, like a BIOS setup GUI where one can choose the needed patches to avoid wasting SRAM space. The main question is how much free space is available for additional software in the new custom ROM ?

Thank you once again for the good news. This was a very positively shocking moment

Keep the scene alive !
Eidis

[lydux]

I'll focus on x68000 models, which have 128KB of reprogrammable ROM space (x68030 have 256KB).
The bios itself is bit less than 64KB (even 1.3 bios), the other 64KB contains the builtin debugger which can be safelly removed.
64KB is 4 times the SRAM, this leave a pretty large amount of space for customization !
Also, I think the bios can be largelly stripped down by removing some IOCS functions.
IOCS functions are routines provided by the bios for easy hardware access and usable by post-bios programs (SRAM or operating systems). To me, such functions like printing, painting or Kanji/Romaji characters code convertion does not have their place within the bios. They aren't used by any SRAM based program and so, can be provided as a Human68K driver as necessary.

About embedding Human68K, you must know that every bios already provide a v2 one. However, there is just the kernel, a printer driver and a serial terminal. No command line interpreter (command.x), so totally useless nowadays.
I tried creating a compressed ROMFS containing HUMAN.SYS v3, COMMAND.X, an ramdisk driver and a RS232 file transmitter. Unfortunatly, I miss few KB.
However, I think creating a small command line interpreter like the one provided by modern embedded bootloader is possible...

Well... Before that, let's start with something simple :
- IOCS based on 1.3 bios
- Add a better errors handler (will help me for bug reports)
- Isolate IOCS block devices access routines (FDD and SCSI)
- SASI driver integration
- Boot screen reworking
- Reworking of the stage 1 boot (searching for bootable devices, alternate boot methods, request for bootable floppy)
- Various text translations

Right now, I'm performing a bit of cleaning of the bios reversed source code and developping a simple ASM/C framework for easier futur developments.

Stay tuned !

[SQZ]

Wow! Awesome news lydux!!!

Thank you for this big effort!!

[eidis]

 Hi Lydux !

Thank you for the news and keep up  the good work ! I can help with the translations if you want.

Keep the scene alive !
Eidis

[BlueBMW]

One thing I noticed was when running a hard drive on a SASI based system I never could get 2HDBOOT games to work.  I assume this is a limitation of SASI based systems and how SRAM is used on boot to run such things.  Is there a possibility to regain 2HDBOOT functionality on SASI systems with what you guys are talking about here?

[eidis]

 Hi BlueBMW !

2HDBOOT games in Games3 require 4MB of system RAM. Flying Shark and Image Fight run fine with this amount of RAM and they both were tested on an ACE HD. What happens when you try running them ?

Keep the scene alive !
Eidis

[BlueBMW]

Hi BlueBMW !

2HDBOOT games in Games3 require 4MB of system RAM. Flying Shark and Image Fight run fine with this amount of RAM and they both were tested on an ACE HD. What happens when you try running them ?

Keep the scene alive !
Eidis

I dont have the computer with me any more but it was an Expert with 4mb ram.  I cant remember what all games I tried but I seem to remember anything with 2HDBOOT would not run on that system.  Ram tested fine and games that natively could use 4mb ram like Cotton would utilize the ram when booted from disks.

[lydux]

Humm... Eidis ! Thanks for your proposal on translation, but the bios itself does not contain so much text. It has been already done.

However, there is one little documentation from programmer manual related to the IPL I need to translate. It will help me a lot in understanding some bios part if I could have it fully translated.
Here is, with some already translated part :

http://pastebin.com/AC6gNzJ7

Thanks to anyone helping !

One thing I noticed was when running a hard drive on a SASI based system I never could get 2HDBOOT games to work.  I assume this is a limitation of SASI based systems and how SRAM is used on boot to run such things.  Is there a possibility to regain 2HDBOOT functionality on SASI systems with what you guys are talking about here?

I never used 2HDBOOT, but look at the source code. If I remember correctly, it loads a full floppy image into RAM, replace some disk access routines in order to read/write from RAM instead of floppy, and perform a bios reboot at some point. I guess if there are problems with SASI, that's due to the SASI bootloader (BOOTSET) which resides in SRAM. Depending on your boot order configuration, 2HDBOOT might still let the bios execute it before floppies.

Here the idea is just to integrate the SASI driver along with SCSI and FDD ones. That means the bootloader will remain the same as SCSI leaving the SRAM free. 2HDBOOT should work.

[BlueBMW]

That sounds fantastic!

Now if we could get 2hdboot to work on x68030 machines too....

[eidis]

 Hi Lydux !

Challenge accepted. This should take a day or two.

Update #1: Please have a look at the attached document. You will probably need to verify and correct some of the translations. Waiting for further instructions.

Keep the scene alive !
Eidis

[lydux]

This will help me for sure. Except for the file format (M$ Word is a pain to read for me) and some few translations, but it will be fine as is...

Thanks Eidis !

[eidis]

 Hi Lydux !

Sorry for the caused inconvenience, I will try harder next time. Please let me know if there is anything else I can help you with.

Keep the scene alive !
Eidis

[RetroRepair]

That's so weird, I was looking at those sockets just a few hours ago and wondered what they were for. Then I come on here and find this!

It would be fantastic to make this wonderful system a bit more accessible without special hardware to write disks etc. Will be keeping a keen eye on this!

[lydux]

Guys ! I need your help.

I'm currently implementing a block device driver layer within this bios. And for the sake of compatibility, I need to write an SxSI probe interface.

So, I need to know how the computer will answer to a certain access depending on the current hardware. But I do not own all X680x0 models, and no SCSI card at all...

All you have to do is downloading this little human68k program, and execute it on your x68k. It will probe for the SASI and SCSI controllers, and print particular values. I'm expecting different results depending on your x68k model and eventual SCSI boards.

Please report to me values you get, the x68k model it was run on and your eventual attached SCSI board model.

For example (my result) :
Model : ACE HD
SCSI board : none
SASI SR=0xff00
SPC SSTS=0xffff

Thanks for your cooperation ! 

[BlueBMW]

Lydux.  If you need a SCSI board I have several extras.  Let me know if you want one and Ill send it to you.

[eidis]

 Hi Lydux !

Here are my results:

Model : ACE HD
SCSI board : none
SASI SR=0xff00
SPC SSTS=0xffff

Update: Here are some other results after experimenting with XM6 TypeG

SASI/SxSI/SCSI External
SPC SSTS=0xffff

SCSI Internal
SPC SSTS=0xff04

SASI SR in all cases stays the same.

Keep the scene alive !
Eidis

[costa]

Hi,


A few that I can provide now.

Model : XVI HD
SCSI board : internal board
SASI SR= 0xff00
SPC SSTS= 0xff04

Model : Expert HD
SCSI board : none
SASI SR= 0xff00
SPC SSTS= 0xffff

Model : 68030
SCSI board : internal board
SASI SR= 0xff00
SPC SSTS= 0xff05

Model : Super HD
SCSI board : internal board
SASI SR= 0xff00
SPC SSTS= 0xff05

Model : ACE HD
SCSI board : none
SASI SR= 0xff00
SPC SSTS= 0xffff

Now I inserted two SCSI boards I have into the ACE and run sxsiprobe.x again. Values I got were the same when th SCSI boards were not plugged.

Model : ACE HD
SCSI board : SHARP CZ-6BS1
SASI SR= 0xff00
SPC SSTS= 0xffff

Model : ACE HD
SCSI board : SACOM 0661
SASI SR= 0xff00
SPC SSTS= 0xffff

[lydux]

Thanks a lot to both of you !
It will be enough with with these tests.
I might ask for another similar test soon as I realize external board use another address space than internal controller and also that I was not expecting this SASI SR value with SCSI models...

It means SCSI based models still have a SASI controller or the SPC controller override it.

[X-Col]

Apologies for bumping this post, but I was wondering if there was any progress on this?
I too am pretty keen on the idea, and have an EPROM programmer...

[costa]

Don't apologise, X-Col.
This a a super hot topic, I too have dreams of replacing my X68000 boot ROM with something ... salty!!

Apologies for bumping this post, but I was wondering if there was any progress on this?
I too am pretty keen on the idea, and have an EPROM programmer...

[X-Col]

Apologies for bumping this post, but I was wondering if there was any progress on this?
I too am pretty keen on the idea, and have an EPROM programmer...

I know this is an old thread, but I had high hopes for this.
Is the idea now dead, or is work still secretly happening in the background ?

I hope it's the latter!

[sjamaan]

Any updates from this? I tried to contact lydux but no dice...
I have burned some 1.3 roms and put them in the system but I think they are expecting  the SCSI etc...
and just says reboot...
I saw on some Japanese site that said that issues with overclocking can be fixed by putting XVI roms
in your system...
I would like to try that...too...

anyway, I would like to at least get some custom 1.3 ROM that has the nice BIOS post and maybe some daigROM stuff...

just checking...

[kamiboy]

Lydux has been MIA for many years now. I think we can safely consider all the projects he was working on as officially dead. A shame too, he was a wizard level coder with priceless arcane knowledge of this mysterious system we all love.

[leonk]

Lydux has been MIA for many years now. I think we can safely consider all the projects he was working on as officially dead. A shame too, he was a wizard level coder with priceless arcane knowledge of this mysterious system we all love.

Yeah.  It seems that right before Christmas 2014 is when he went MIA .. his ID on github even went dead at that time.  Not a good sign. 

[ShootTheCore]

Too bad.  Hopefully someone can pickup the project and make a go of it.  A diagnostic BIOS that could scan and identify hardware issues would be invaluable in bringing dead X68000 hardware back to life.  I know I could use one.

[neko68k]

There's not very much space in the ROM. You could strip out the Human 2.0 fallback stuff and the kernel debugger I guess but I dunno. It's also kind of a mess in there but what isn't I know it's possible to run newer ROM's on older machines up to a point but I'm not clear on the details and I'll never find that twitter thread again -_-