Floppy drive diagnostics help

[caius]

Among the options in SWITCH.X I see something about ramdisk and S-RAM.

I know S-RAM is 64k big, so is it possible to install a very basic Human68K to S-RAM and route the machine to boot off of it instead of having to boot off of a floppy every time?

Could be a nice fail safe in case the floppy drive goes bad again.

Good question,I don't know.For use you can install in SRAM some drivers which allow you to boot from external FDDs.
Now that your FDD works again , have you tried your PowerMonsterII?

[kamiboy]

I wish there were more and better english language sources to turn to for detailed technical information on the inner workings of X68000 and its OS.

The more I think about it, the more impressed I am by how well engineered it is for something that came out in 1987.

I could see myself maybe doing some coding on this thing. There is a C compiler for it and everything, but programming information is prolly nigh on impossible to come by in any language that I speak.


As for the Power Monster II, well, at the time I had no faith in being able to restore the Compact floppy to working order so I sent it back to Sakai and asked him to replace it with an AztecMonster. It should be in my hand this coming week.

Unfortunately The AztecMonster is bigger, and needs a seperate power source which means it is a much worse fit for internal installation in a Compact, but beggars cannot be choosers as the saying goes.

[lydux]

Among the options in SWITCH.X I see something about ramdisk and S-RAM.

I know S-RAM is 64k big, so is it possible to install a very basic Human68K to S-RAM and route the machine to boot off of it instead of having to boot off of a floppy every time?

All X68000 models have 16 KB of SRAM. Only X68030 series have 64KB.
The minimal requirement to get a usable Human68k v3 is its kernel (HUMAN.SYS), the commands interpreter (COMMAND.X), and an early human68k boot driver. All needs to fit within a filesystem so will be about 90KB big. A bit too much and you will just be able to do basic useless stuff (dir, mkdir, ...) because of missing tools and preloaded drivers like floppy, scsi or rs232.

The SRAM as RAMDISK stuff within SWITCH.X will reserve the entire available SRAM as a FAT filesystem and will allow you to put some small files within it. But again, you will need a driver (SRAMDISK.SYS) loaded first in order to use it.

Just to let you know : there is a human68k v2 kernel embedded inside the bios plus a romfs that contains only a basic serial terminal soft (TERM.X). It was intended to use the x68000 as a diskless terminal machine. Unfortunatly, have no use for us because of a missing COMMAND.X...
When I saw this, I were wondering if we can't just strip-down the IPLROM to minimal stuff, and use the remaining free rom space as a compressed Human68k FS.
The idea is to create a newer bios that will fit within 2 eproms socketable on every X68000 models.

I wish there were more and better english language sources to turn to for detailed technical information on the inner workings of X68000 and its OS.

The more I think about it, the more impressed I am by how well engineered it is for something that came out in 1987.

I could see myself maybe doing some coding on this thing. There is a C compiler for it and everything, but programming information is prolly nigh on impossible to come by in any language that I speak.

I think I know this machine pretty well now. My problems is just that I lack of time and suck at writing stuffs... -_-
There is so many things to know about the x68000.
But feel free to ask for something particular, I will be glad to answer you.

[caius]

I think we must also focused our attention to find a proper way to  replace these very fragile CompactVI FDDs.I contacted Jeff from HxC SD emulator and I told him that full schematics of X68000 are now available if he want to implement  floppy extra features into his hardware but I didn't get any reply.

[kamiboy]

Thanks for the information lydux. If my fancies of programming are not half hearted and quarter assed like all my fancies usually are then I might take you up on that.

By the by. Judging from some programming documentation that I found switching between 31khz and 15khz in games seems to be as easy as changing a single bit in a specific area of the main memory, is that correct? If so then it should be more or less easy to hack 15khz into games?

As for that HxC thing, personally I rather keep my Compact floppy drives for the sake of aesthetics. If I get a CF internal SCSI drive going then the floppy drives basically become obsolete anyway, right?

[caius]

As for that HxC thing, personally I rather keep my Compact floppy drives for the sake of aesthetics. If I get a CF internal SCSI drive going then the floppy drives basically become obsolete anyway, right?

Yes, they will be quite useless,infact I totally remove both of them  from  my CompactXVI

[kamiboy]

I thought Compacts refused to start if the floppy drives were not connected.

[caius]

Yes, it's true. I forgot to mention that I use external FDDs instead of internal ones.

[kamiboy]

Not those rare and elusive 5.25" external FDD's for the Compact that can be had for a sultan's sum?

[caius]

No, I understand what you mean.I use regular 3.5" FDD (two Samsung SFD-321B with 3-mode jumper ON) wired to external FDD connector.I could also connect regular PC 5.25" FDDs or X68000 5.25" ones (not the one from PRO model since they have diffferent pinout for the extra singnals), I have all the diagrams ready, it's just matter of building needed cables.

[kamiboy]

If I had some original games for the X68000 then I wouldn't mind having those external 5.25" drives.

There is something novel about having the machine boot into the game automatically rather than typing a couple of commands on a command prompt to get a game going.

In that regard, and if I find I can motivate myself to do it, I would like to see whether I can cook up some sort of a game launching frontend for the X68000.

Something like a simple grid of pictures representing games that you can scroll through and launch with a joypad. One could throw it into Autoexec and have the system boot into a front end everytime like a MAME machine rather than be greeted with an inelegant DOS prompt every time.

Nothing but a glimmer in my eye at this point, so we'll see.

[BlueBMW]

But the command prompt is all part of the fun of using an old computer.  Everything uses pretty GUIs nowadays.  Theres something special about typing commands into a prompt.

That said, there are file explorers like what is used on the eidis / superdeadite hard drive images.

[lydux]

Off topic :

By the by. Judging from some programming documentation that I found switching between 31khz and 15khz in games seems to be as easy as changing a single bit in a specific area of the main memory, is that correct? If so then it should be more or less easy to hack 15khz into games?

Unfortunatly no, it's not as simple as this. You are probably refering to CRTC's bit 4 on register R20 which allows the horizontal video frequency to switch between 15khz and 31khz. Changing this bit isn't enough as all others CRTC registers which contains horizontal and vertical video timings are still configured to work for 31khz. You need to change them as well. And these timings depends on the choosen game resolution/engine. The x68000 CRTC is highly versatile, allowing many possible resolution for various monitors.
Also, the sprite register and video data selector needs to be configured in accordance to CRTC timings or sprites/background could be drawn at unwanted locations.
Sharp provides some preconfigured generic resolutions and timings for the original monitor available using the bios function call 0x10 (_CRTMOD), but using it is optional and many games doesn't (Final Fight for example).

IMHO, the best way to force a game starting into 31khz is to use its own default values. Most of those 15khz games also provides an option to switch to 31khz. I would just find the default configuration settings within program code (generally, looks like an array) and change it.

But the command prompt is all part of the fun of using an old computer.  Everything uses pretty GUIs nowadays.  Theres something special about typing commands into a prompt.

That said, there are file explorers like what is used on the eidis / superdeadite hard drive images.

Shhhh.... I wanna see some NFG homebrew apps for x68000 !

[kamiboy]

Bah, figured it wouldn't be so easy.


Sounds like changing from 31 to 15khz will break a bunch of things that I have no idea how to fix. I wanted to see if putting 15khz support in some 31khz only games was possible or not. There is no reason why R-Type should run in 31khz for an example. To me 31khz is an eyesore when it comes to lowres sprite games. I need those scanlines.

As for homebrew, before I start on a big project I have something else in mind.

In another thread an app that behaves like FDR for the X68000 was requested.

You know, that is a real good idea. I just need some good detailed low level information on how to check for bad sectors on a floppy.

I assume most applications use generic DOS calls to read and write files off of floppies and hard drives. But what about reading random sectors on a disk? I imagine there must be some way to do it.

[lydux]

That's right !

Reading and writing files will involve both the target block devices and the filesystem, so in short accessed via DOS system calls OPEN, READ, WRITE, SEEK, CLOSE, etc...

These same service functions will use BIOS system calls located within the IPLROM to access block devices.
BIOS system calls are also known as IOCSCALLS and are also accessible from Human68K.
Block devices access functions group start at iocscall vector 0x40 up to 0x4f.


I guess you already have found it, but the x68000 punigrammer pack is a good litterature : http://nfggames.com/x68000/Mirrors/x68pub/x68tools/PROGRAM/ETC/PUNI5_1.ZIP
This archive from NFG is the original in japanese, but I've seen a beggining of translation in english somewhere...

[caius]

I guess you already have found it, but the x68000 punigrammer pack is a good litterature : http://nfggames.com/x68000/Mirrors/x68pub/x68tools/PROGRAM/ETC/PUNI5_1.ZIP
This archive from NFG is the original in japanese, but I've seen a beggining of translation in english somewhere...

Here, my dear Master :

http://daifukkat.su/wiki/index.php/X68000

[lydux]

This is Trap15 wiki, which has nice infos as well (thanks to him btw!)

I was talking about this one (at Data Crystal) : http://datacrystal.romhacking.net/wiki/Sharp_X68000

[kamiboy]

Yeah, I've already found both and had a cursory gander through them.

I also found your windows x68k tool chain, and I am in the process of setting that up.

How do you test the code you write via said tool chain? In spits out a .X file at the end but how do you get that into an emulator to execute it in a timely manner?

[caius]

Yeah, I've already found both and had a cursory gander through them.

I also found your windows x68k tool chain, and I am in the process of setting that up.

How do you test the code you write via said tool chain? In spits out a .X file at the end but how do you get that into an emulator to execute it in a timely manner?

Put the resulting .X file into a blank formatted disk image file (or use windrv.x to mount Windows devices),  mount this into XM6 emulator and executes the .X file from '0' or '1' virtual FDD.
You can create a blank disk image in .XDF format just under XM6 (go to Tools --> Make a new Floppy Disk) and then browse and upload files to it using DiskExplorer utility which you can download here:

http://hp.vector.co.jp/authors/VA013937/editdisk/editd169e.rar

[kamiboy]

Thanks, I knew it would have to be done by somehow getting the binary onto a disk image, I just didn't know there was a tool to move files onto such an image easily.