• Please review our updated Terms and Rules here

Got CF cards to work on Tidalwave palmtop

theancientone said:
I see, so it does not matter if I use a different CF card or a different CF adapter; as that should not affect things at all.

1) If I just start the driver, and do not do anything (so I leave the SRAM card in slot A); if I try to access the SRAM, I get the error as the drive cannot be accessed.
Click to expand...
Very strange. Palmtops.net says that the Prolinear is exactly the same as the Tidalwave PS-1000, without any changes or even custom branding, but there must be an actual difference in either the hardware or ROM software for this to happen. I can't imagine what that would be.


theancientone said:
2) When I run the format I get an error saying that it cannot write block 0. I run format command for a: and it tell me that the drive seems not formatted, asking if I want to format it (y or n). I press Y and right after it fail saying that it cannot write block 0. I can take a screenshot of the screen so you can see all the lines.
Click to expand...

That screenshot would be helpful. The format program isn't exactly great quality (that's why I didn't include the source code in the archive), and I may need the exact output to try to piece together what went wrong.

theancientone said:
The weird thing is that nobody else using this driver seems to have any issue. What is the actual workflow to use the driver? I can follow your steps to the letter and at least start from a known state at least.
Click to expand...

One more thing to try would be:

- make extra sure the CF adapter is removed
- reboot the palmtop while holding Alt + Shift
- a menu should appear, select option 8 (boot from ROM with no startup files)
- now go to A: and run the driver, see if the error persists

Maybe I could also write some kind of debug program that double-checks every step and provides more detailed technical information, but that won't happen in a single day.
 
dreNorteR said:
Very strange. Palmtops.net says that the Prolinear is exactly the same as the Tidalwave PS-1000, without any changes or even custom branding, but there must be an actual difference in either the hardware or ROM software for this to happen. I can't imagine what that would be.




That screenshot would be helpful. The format program isn't exactly great quality (that's why I didn't include the source code in the archive), and I may need the exact output to try to piece together what went wrong.



One more thing to try would be:

- make extra sure the CF adapter is removed
- reboot the palmtop while holding Alt + Shift
- a menu should appear, select option 8 (boot from ROM with no startup files)
- now go to A: and run the driver, see if the error persists

Maybe I could also write some kind of debug program that double-checks every step and provides more detailed technical information, but that won't happen in a single day.
Click to expand...
Indeed they are the same; as all the clones; but I suspect something is different either in the ROM addresses or in some components... It is peculiar that I am the first to report this issue, among all the users of this driver, and I assume most people are using either the official Tidalwave or the Zeos maybe? The videos I found on Youtube mentioning your driver (this is how I found it) were using a Zeos device.

Thanks! Following your steps I was able to boot in the "startup" menu (which BTW will not work if your device is password protected), and using option 8 I was able to access the CF card. The SRAM card is still not accessible once I load the driver, but at least I can access the CF card; and when I reboot in "normal mode" the SRAM card works again.

If you have a way to print debug info I would love to see what is going on here... Maybe the ID memory address for the drive A and B are overwritten on this specific model when you run the driver? I remember your previous driver version required to pass a flag to specify which drive to mount? Maybe that is the issue?
 
That's a very weird and specific failure mode!

Anyone, including me, would have expected the CF support to be where things go wrong, even without considering the huge power draw making it unstable:

a) it has to detect that a card is present at all

b) it then switches to attribute memory space and parses enough of the Card Information Structure (CIS) to see it's an ATA card; I have written some rambling technical details earlier in the thread of how I first got the control port command for this to work by accident, and then gradually figured out how to do it properly

c) to actually read anything, it has to send sector number etc., and wait for a response from the card. This could time out, or return some error instead of the data we want.

For SRAM cards, step a is the same; it would then go on to attempt b, and conclude that it's probably an SRAM card when it either can't find a CIS, or it's different from what the documentation for ATA cards says it should be. The card is directly mapped into memory, and should work just like a RAM disk.

What might have happened is that somehow, it didn't actually override the built-in driver for A:, but again I have no clue why. They should be identical! Or it's reading garbage data from the card, again no idea why.

I think I'll get started on writing some test program to get more information. That the CF card for some strange reason works seems like a really good opportunity to get a full ROM dump off the machine, I already have one for mine though it's the German language version.

***
warning, more technical rambling ahead that has no relevance to your problem. feel free to skip this!
***

I've been going through that ROM a bit, since your post somewhat rekindled my interest in figuring out more about this machine. The "slack space" at the end of files in the drive C: and D: images contains some directory entries that seem to be left-over garbage out of the disk buffers from whatever PC was used to build the ROMs. No source code, but some interesting file names:

Code: 
Build environment:

attrib name    .ext       size date       time     cluster#
----D- BINARIES.             / 1980-01-01 11:03:18 0849
----D- BIOS    .             / 1980-01-01 11:03:50 0D93
----D- BOOT    .             / 1980-01-01 11:04:22 13B6
----D- CMD     .             / 1980-01-01 11:04:24 13E7
----D- COMPRESS.             / 1980-01-01 11:05:28 1F48
----D- DEV     .             / 1980-01-01 11:05:46 22CC
----D- DOCS    .             / 1980-01-01 11:06:34 2C22
----D- DOS     .             / 1980-01-01 11:08:24 4078
----D- LIB     .             / 1980-01-01 11:11:16 5A9F
----D- MESSAGES.             / 1980-01-01 11:11:18 5B12
----D- MKIMAGE .             / 1980-01-01 11:11:18 5B4A
----D- ROM     .             / 1980-01-01 11:11:20 5B9C
----D- ROMHEAD .             / 1980-01-01 11:11:28 5D60
----D- ROMIMG  .             / 1980-01-01 11:11:28 5D74
----D- ROMLOAD .             / 1980-01-01 11:14:08 794F
----D- TOOLS   .             / 1980-01-01 11:14:10 79A0
----D- GER     .             / 1992-08-20 12:54:54 61B7
----D- SPA     .             / 1992-08-20 12:54:56 61ED
----D- FRN     .             / 1992-08-20 12:54:56 6225
----D- RPP     .             / 1992-12-05 10:22:00 5EE4
----D- S-ICE   .             / 1992-07-21 15:05:26 0481 Soft-ICE?
----D- RPP     .FRA          / 1992-07-16 19:14:36 989F
----D- WORKS   .FRA          / 1992-07-16 19:14:32 989E
----D- FLOPBOOT.             / 1992-05-19 22:23:28 5171
------ MAKE    .          1194 1991-10-23 15:36:26 0848
------ ROMDOS  .LOG       8298 1991-11-08 14:44:06 0831 log from DOS build process?
------ ROMESP3 .LOG      33857 1991-10-01 13:43:32 0837 another large log file
-----A TOMS    .BAT         97 1992-01-09 17:20:12 677F To MS(-DOS)
-----A TODR    .BAT         97 1992-01-09 17:20:36 6780 To DR(-DOS)
-----A MKTSTROM.BAT        842 1992-03-14 13:43:10 551E make test ROM
-----A ROMDISK .EXE      24940 1991-10-16 06:00:00 551F
-----A REBUILD .BAT        247 1991-11-22 17:08:10 52B5
-----A MK15ROM .BAT        513 1992-03-23 20:23:28 52B6
-----A APP     .BAT       1268 1992-01-14 10:38:12 53F5
-----A HIGHLOW .           794 1991-08-20 11:31:40 4E23
-----A HIGHLOW .BAT        230 1991-08-20 11:31:40 4E24
-----A MAKEFILE.          1238 1992-05-01 09:36:10 4E1C
-----A MINIMUM .           864 1991-08-20 11:31:40 4E26
-----A MINIMUM .BAT         36 1991-08-20 11:31:40 4E27
-----A ROMIMG  .TAG        480 1991-08-30 08:12:26 52D4
-----A ROM1    .ROM        212 1992-06-22 15:22:44 50C7
-----A ROM2    .ROM        189 1992-06-22 15:20:50 4F18
-----A ROM3    .ROM        247 1992-06-22 15:22:44 50C8
-----A ROM4    .ROM        125 1992-05-01 09:53:24 4E36
-----A ROMHEAD .LOC         71 1992-06-22 15:21:14 4F6C
-----A COMMAND .LOC         73 1992-06-22 15:21:20 4F87
-----A RESBIO  .LOC         70 1992-06-22 15:21:22 4F8E
-----A ROMBIO  .LOC         70 1992-06-22 15:20:58 4F2C
-----A ROMDOS  .LOC         69 1992-06-22 15:20:58 4F2F
-----A ROMLOAD .LOC         72 1992-06-22 15:21:20 4F89
-----A ROMBOOT .LOC         71 1992-06-22 15:20:52 4F1B
-----A HEAD1   .LOC         64 1992-06-22 15:21:04 4F42
-----A RESCOM  .LOC         67 1991-11-13 11:00:06 4F9C
-----A COPYB   .BAT         37 1991-11-22 16:02:32 4F9D
-----A CHINESE .BAT        108 1992-03-18 20:00:32 4F9E

LiteOn (the company making optical drives?) keeps popping up, first seen in the special boot signature and now here:

-----A LITEON  .BAT        525 1992-06-18 16:46:36 61C8
-----A LITEON  .BAT        497 1992-06-22 15:38:58 6C44 another version
-----A LITEON  .CHR        507 1992-06-18 14:36:42 630D
-----A LITEON  .           983 1992-01-29 10:41:44 4F43

A few assembly source and object files:

-----A SPT15M  .ASM       3501 1992-02-22 16:13:02 4FA0
-----A SPT512  .ASM       3510 1992-03-15 10:53:58 573F
-----A SPTCHRIS.ASM       3500 1992-06-18 13:43:08 2533
-----A SPTCHRIS.OBJ        897 1992-06-18 13:43:26 2535
-----A SPTCHRIS.EXE       2088 1992-06-18 13:56:06 2536
-----A SPTMSK  .ASM       3515 1992-06-18 16:48:06 61C0
-----A SPTMSK  .OBJ        808 1992-06-18 16:52:14 61C6
-----A SPTMSK  .EXE       2043 1992-06-18 16:52:22 61C7
-----A SPT1MD  .OBJ        802 1992-06-20 11:39:32 6669
-----A SPT1MD  .EXE       2037 1992-06-20 11:39:38 666A

Various ROM images:

-----A LITEON  .BIN     131072 1992-06-22 15:26:26 6127
-----A 480K    .BIN     491520 1992-06-18 16:01:36 5873
-----A XT32T   .BIN      32768 1992-04-21 20:10:56 52A5
-----A D000    .BIN      65536 1992-01-28 18:41:54 52D5
-----A LITE    .BIN     524288 1992-05-13 15:13:28 52F5
-----A ROM2    .BIN      32768 1992-06-18 15:59:40 563A
-----A LITE    .CHR     524288 1992-06-18 14:38:26 696B
-----A ROM1    .BIN      32768 1992-06-22 15:22:54 50D9
-----A TT      .BIN    1048576 1992-06-20 18:03:42 7D4A
-----A WORKS3  .GER     524288 1992-06-22 12:20:56 995B
-----A WORKS1  .CHR     524288 1992-06-22 15:27:32 647F
-----A D800    .BIN      32768 1992-06-22 15:22:54 60E7 Boot loader and ROM-DOS code
-----A DOS     .GER     524288 1992-06-20 18:04:38 8C35

Deleted files / directories:

----D- ?RJ     .             / 1992-08-21 18:08:08 0899 ARJ?
-----A ?PCGA   .EXE     166347 1992-10-16 12:21:00 9448 RacePen
-----A ?PCGA   .EXE     166356 1992-10-17 11:43:00 9639 another version
-----A ?SKENVIR.BAT       1068 1992-02-03 05:00:00 630C set up DiSK environment?
-----A ?OMENVIR.BAT       1014 1992-05-20 00:07:22 630D ROM environment?
-----A ?ETLANG .BAT       5580 1992-02-06 10:52:16 630E set language of ROM?
-----A ?ITEON  .DR         681 1992-01-14 10:37:44 677E LITEON again
-----A ?R      .NEW     524288 1992-01-10 11:45:14 6781 ROM disk image with DR-DOS?
-----A ?RIP    .CHR       7241 1988-08-29 02:00:00 5419 font from Borland graphics library
-----A ?12K1   .BIN     524288 1992-03-22 15:16:12 541D ROM image
-----A ?T      .BIN     524288 1992-04-21 20:22:14 552C ROM image
-----A ?12K    .MS      524288 1992-01-15 17:00:26 562C ROM image, MS-DOS version
-----A ?T32T   .OLD      32768 1992-01-08 14:15:32 572D BIOS?
-----A ?PT512  .OBJ        807 1992-03-15 10:54:20 5742
-----A ?OM3    .TMP      65536 1992-06-22 15:23:04 50EC

I've also found yet another way to run code from an inserted SRAM card on boot. This one doesn't even need a special boot sector, just a file that looks like an option ROM image anywhere in the first 16K. The BIOS will jump directly into it! Today such a thing would be considered a critical security issue :)

However when I tried it out, I could make it print a message to the screen and wait for a key to continue, but then it hung the machine. There may be some power management thing going on where it shuts off the card while waiting for the key press - would hope to figure out how to use this to make CF cards be more battery-friendly!
 
Indeed I have no clue why things are happening the way they do... This machine is a black box to me, I have no way to see what is going on nor there is any material that show how it works. So it is a matter of just throwing things in and see what sticks. At least I am glad it DOES something now by booting without drivers!

How does the device know that there is a card in the slot? Is one of the pins going low (or high) and that is enough to set the state in the bios? Could it be a timing issue due to some race conditions on my device, where the response is either coming back from the device too fast or too slow than expected?

Interesting stuff you found in the ROM; how did you find it? As far as LiteON, I am not surprised to see its name, as it is also a Taiwanese company, which exist as long as Tidalwave; so it is not far-fetched to think that they had some relation/interaction of some sort and the device still has some traces of it in rom :) I wish there was someone still alive to dump some info on this machine and its history :D
 
The last version I uploaded still had the works-by-accident method of switching to attribute space. I made a new one that does it properly and might be more compatible, and also fixed an off-by-one bug where it wouldn't allow access to the very last sector.

There is now some very experimental power management: when going to sleep, it does a few port outputs that should hopefully power down the cards, we'll have to see how much of an effect this has. SRAM cards unfortunately seem to sometimes not "wake up" immediately, but they should work again after choosing "Retry" at the error prompt. Might also be my dodgy hardware.
 

Attachments

Annnd... I was being overoptimistic again :( Batteries are already empty despite not much active use, just leaving it "off" (suspended) with the card plugged in. Maybe there is some super-secret combination of pokes to make this thing's power management not suck, but if it exists the code in ROM certainly isn't doing it!

I've been going through some of the important seeming parts of the BIOS in IDA, and there's stuff like this:

- On reset, 00h is written to port B0h (which disables something in the PCMCIA interface, but apparently not enough)
- Before accessing a card, it writes 01h to that port and loops until the card indicates 'ready'
- I can't find any place where that port is ever set to zero again, so it stays enabled

So I tried writing zero before chaining the original NMI handler (which powers off the machine). Seems to cause some extra problem with SRAM cards, but would be worth that if it actually did save any power.

When waiting for a key press, the INT 16h handler enters "idle mode" by writing 51h to port EEh/EFh index 3Ah. This might also do something with PCMCIA? Did that too, then noticed that the NMI handler turns that mode off again (by writing 00h to index 00h, naturally).

There is a hidden extra 16K of video RAM that is used to store some variables, and for saving the screen when it displays a battery warning message. To access it, the BIOS first reads register 12h at the CGA's port 3D4h/3D5h, which then unlocks register 20h. Write 01h to that to enable the extra memory, 09h to hide it. Finally, read register 13h to lock the control register again.

And this is probably a good example of how nearly everything on this machine tends to work. Worst thing is that there's probably so much more functionality which the BIOS code doesn't use, so the only way to find it is to try every random thing. Yes, I'm a bit frustrated right now.
 
Took me forever to work around this, but eventually got it on the device.

So far I noticed minimal difference in how the device behave, so I suspect there must be a difference in how the bios has been written, as I swapped A to B for example (so used SRAM in B and CF in A) and the card that get deactivated is always the SRAM once I run the drivers.
Power-wise, I noticed a difference in behavior with and without the cf card in, as it seems that the drivers are using more power even with the card off. I cannot quantify but the batteries were sucked dry not in a day as if I had the CF card in, but if I run the drivers and then push the power button, the batteries do drain faster for sure (like in a week the batteries were empty). I will try again resetting the device, and this time not running the drivers and see how long the batteries last.

I am amazed how nobody on the internet has the technical manual for these devices; it would really help to get the ROM map and the original tech documentation to figure how the power management works :( Thanks for your hard work BTW, it is really a miracle what you are doing out of nothing basically, since there is virtually nothing but the reverse engineering efforts you are doing. If you have any clue of how can I dump my ROM and disassemble it, please let me know and I will give a try, although I have no serial cable... So unless there is a way to make an alternative cable, I can only use the SRAM card as IO :(
 
You must log in or register to reply here.
Back
Top