-
First I tried S1 not S0, because all my cables are too short to plug the drive on the non twisted connector.
Then I thought OK maybe the FDC in the programmer can only work if the drive is set to S0, so I managed to relocate the drive so that I was juuuuust abotu able to plug a straight cable to the drive. Just.
Still, no joy.
However, now I think about it, I never tried using a straight cable in the PC.. because well, the drive was working find with the twisted cable that was already in place, so why bother.
So I think I will try to do that... just in case somehow, the drive somehow developed a fault that makes it fail to work in S0. Not likely, but who knows... at least I would be able to say I tried absolutely every thing.... when you don't know what the problem is, you need to try absolutely every thing you can think of... because if you don't, Murphy will make sure that the actual problem was the ONE thing you did not think or care to try out.... eh ?
Stay tuned. -
My intuition says that it's still a bad contact somewhere.
Can you see that all connections are visually ok when all things are in place?
About dd,
it read blocks, no matter what, but blocks must be there.
ImageDisk is a normal data reading and writing software but it is using disk controller to its limit.
For example, it can't create sectors any longer than controller accepts or support.
If you check that earlier link and its yellow background picture there are those extra bytes.
Those are partially coming from the controller and nothing can change that.
dd is not reading or writing any of those extra bytes.
Normally hard disk blocks are always there but that has not been the case earlier.
Back in the day when hard disk had a different interface the situation was like with floppies.
You had to do FDISK first, and it did some real work, like formatted tracks.
Only after that you were able to partition the drive and format it again, but that format was practically read only.
Bad sectors were also something totally different thing than today.
Some other nuances from the past.
SSSD Single Side Single Density, 5.25" 35 tracks, 160k 300rpm.
DSSD Double Side Single Density, 5.25" 35 tracks, 320k 300rpm.
SSDD Single Side Double Density, 5.25" 40 tracks, 180k 300rpm.
DSDD Double Side Double Density, 5.25" 40 tracks, 360k 300rpm.
SSQD Single Side Quad Density, 5.25" 80 tracks, 320k 300rpm.
DSQD Double Side Quad Density, 5.25" 80 tracks, 640k 300rpm.
DSHD Double Side High Density, 5.25" 80 tracks, 1.2M 360rpm.
DSDD Double Side Double Density, 3.5" 80 tracks, 720k 300rpm.
DSHD Double Side High Density, 3.5" 80 tracks, 1.2M 360rpm, NEC.
DSHD Double Side High Density, 3.5" 80 tracks, 1.44M 300rpm.
-
OK, 23H45 time to stop working on the thing, back to work soon...
Spent time doing all sorts of tests on the vintage PC, swapping drives, floppies, cables, BIOS settings... I think I covered it all.
I am now starting to think that my earlier assumption that the straight floppy cable that came with the programmer, was bad.... was wrong.
Turns out that the problem is neither the drive nor its cable... nope. After countless experiments, it turns out believe it or not, that the problem is the old PC itself !
This IBM with proprietary PSU, motherboard and BIOS and cases and everything... which is already known to have compatibility issues with mundane stuff that worked just fine in every other PC under the sun of back in the day.... also does crazy shit with the floppy drives !
I now understand why this PC came with this strange floppy cable that's twisted YET has only one plug, it can only connect to a single drive.. yet it's twisted.
Turns out, the computer will NOT work if you try to use a straight cable with the drive set to be the primary drive ! Nope !
Does not matter if it's my DD drive, or the OEM IBM branded HD drive, or any of the jelly bean HD drives I have in my junk boxes...
If you use a straight cable, the computer fails to boot. The BIOS forces you to visit him, and there you will see that it decided to use the following settings :
Drive A = NOT INSTALLED !!!
Drive B = 1.2MB 5.25" !!!
It does that no matter what drive type I give it.
So then I rectify the settings by hand, so it looks like :
Drive A = 3.5" 1.44MB (the only option for 3.5" drives, but works fine for the DD drive as well no worries)
Drive B = NOT INSTALLED
So I save these settings and reboot and... nope, computer fails to boot again and again the BIOS resets the settings to the weird stuff I just described, it really insists.
So I insist as well : I force it to boot and load MS-DOS, but of course it does not work : drives no matter which one, cause IMD to hang / crash if you try to access the drive to do anything.
So this means I can not use the PC to test if the DD drive works fine with its straight cable as Drive A, so as to rule out a cable or drive selection issue within the drive itself.
So I need to get / buy a different vintage PC, one that's not a proprietary shit IBM... but rather one that uses standard PSU and motherboard and BIOS. More cost. I hope I can find a decent one for cheap locally.
Tried using the DD drive as drive B on the programmer but no joy, still beeps at me at power up.
ALSO
I read the user manual for the 5000. Turns out I don't have 3 different manuals in the end.... no, it's just one big manual, Word document, but they split it into 3 pieces. One of the 3 contains all the stuff about using the serial port remote control. Lots of good pornographic stuff in there, which confirms what we figured out so far.
My conclusion is that the two commands that caused problems and hung the programmer... should have been harmless.
First it hung when I ran the MECK command. This command let's the user calculate the CRC of a given block of data within the user RAM. So you are supposed to follow the command with start/end address parameters, then it will return the Checksum. So what the programmer was supposed to do is reply ERR #1 because the command was invalid since I failed to supply the required parameters.
Instead it just hung. Not normal.
Then the next problem was when I ran the TSDR command. The group of commands that start with TSxx is used to perform tests on the programmer's H/W, for diagnostics purposes.
There are 5 of these commands to test the DRAM, SRAM, CPU ROM, the removable test fixture where you plug the chip to be programmed, and another command to test some module I think you can plug instead of the test fixture.... whatever. None of these commands require parameters. You just type the command name, the programmer tests the DRAM (in my case) and once done it returns 00 to say that the DRAM tested OK (or not)... and it DID do that the first time I typed this command ! It's only the second time I issued it, that it started working on the floppy drive then crash, then fail to boot again and again and again....
Reading the description of some commands, at a quick glance, it looks like it IS possible to mess up the programmer if you use some commands the wrong way, or not in the right order.... so possibly I could have messed it up. HOWEVER it should all have cleared up upon power cycling it, as there is no non-volatile memory in this programmer that I can remember of !
And anyway, if the programmer CAN be rendered non-bootable just by typing some random crap on the serial port, WOW that's a crappy product !
So I don't believe that it is it...
I now think there is a genuine problem and that it's nothing to do with the drive or cable or floppy.
A while back when I started working on this programmer, I noticed that if I shorted the 5V rail, it would reboot itself. Not so surprising I hear you say...
So I think, maybe, that's what happened when I typed that TSDR command.... not because of the command itself, but just that as a coincidence, at the same time maybe some tantalum cap died and shorted the supply, causing the programmer to reboot... but it can't boot now because maybe the failed cap caused more damage around it when it died. Either that, or its absence (open circuit / no decoupling anymore) caused some issue with the integrity of some vital digital signal... most likely in the FDC board of course....
Now I remember it, on that French forum they said that the FDC board had a vital cap used for timing, that liked to fail and caused the FDC / boot to fail !
So I will just pull all 5 boards out of the programmer and inspect all the tantalum and alu cap I can find.... back to basics I say !
One other member with boot problems on that forum also said he had to replace a couple TTL chips, but didn't give any details....
Forgot to say : the manual gives a list / description of tons of error codes but of course does not cover the ones I get...
So maybe they are not "user level" codes, but more low level codes for debug purposes, destined to the engineers designing this thing.
This further reinforces the hypothesis of a board failure....
So for now that's my best guess, please cross all your fingers....
-
Hi Vince,
There is a reason for the twisted floppy cable. Here's an explanation: https://www.nostalgianerd.com/why-are-floppy-cables-twisted/ So the twist is needed even if there is only one drive, A:
Thanks for a very entertaining story. Your persistence is legendary. I'm wishing you successful results. -
Dang, my bad, I've overlooked that cable twist.
Thanks to retiredfeline for pointing that out.
But I still can't get in to my head that PC drive selects are 2nd and 3rd, not 2nd and 1st.
Was the 5.25" twist thinner.
So PC side DS0 is wrong.
Drive pins used to be, and still are for programmer's drive
10 1st DS
12 2nd DS
14 3rd DS
16 Mtr On
So straight cable goes so that 2nd DS and Mtr On are connected.
Twisted goes so that Mtr On goes to 1st DS and 2nd DS goes to 3rd DS.
If PC drive has no drive select then cable must be altered for programmer use.
There straight cable's drive side 1st DS must be cut and connect to 2nd DS.
In case of possible 2nd drive better cut 2nd DS also.
I have two out going Fujitsu-Siemens PCs, but w/o ISA and mechanically less standard so not recommended, including non-standard power with possible leaking caps.
Anyway, I took one FD out, it's Mitsumi D353M3D and it has selections DL1 and DL2 where DL2 is shorted, also DEN1-4 but there are two shorts so they are most likely density stuff, it also has only four down side interface pins.
But DL1/2 are not connected to drive select lines, so no enlightenment.
Pins 12 and 16 has something there, but not shorted together, when 10 and 14 are pretty NC.
Earlier mentioned other Mitsumi has similar construction so didn't open it.
Earlier mentioned Panasonic then has D0/D1.
That bent connector pin then, it may be permanently nasty.
Not electrically, but mechanically it may have a tendency to pull back.
It may also be sneaky and pull back only a bit but still enough to be a trouble maker.
E,
a cut. -
Thanks for that chaps.
Wow... this drive selection problem is incredibly messy and confusing !
I am glad you understand it...stick around please !
I now find it a miracle that floppy drives could work a tall in computers... with so much room for things to NOT work !
Anyway... it should be simple in my programmer.
Drive was set to (D)S0, using a straight cable.
It worked fine.... then all of a sudden did not.
.. but the drive is fine, and I tried 3 different straight cable (or twisted as well), nothing works.... so as I said it looks more like a controller issue than a drive or ribbon cable issue.
The bent pin on the connector, well I am the one who stupidly bent it, it was not bent at the time that the drive/boot failed.
There is ONE last test I can do, stupid me.... again the last and most important test I must do is test the original straight cable that came with the programmer, coupled with the DD drive set to S0.... well I know where I can find a PC to do that ! .. well, not the vintage PC sadly, but... well my main Linux PC should be just fine for that !
So let me try that out and we will soon be able to rule out (or not...) both the DD drive and its original cable. Once that's done I will have piece of mind and will embark into working on the floppy controller board....
Stay tuned... -
OK that was waste of time... my Linux PC is doing weird floppy stuff as well.
I give up, I am done for now, need a break.
I will resume work on this thing once I have finished up a few long overdue little projects that will allow me to remove some stuff from the bench, gain some space to work properly and more confortably on this bulky transformer. So far I have been in quick 'n dirty mode, but clearly we are past this stage and we are deep into this thing now. I need a longer term "bench" solution... not the current mess.. I have reached the limits of what is humanly possible.
Need to spend some time finding a decent Vintage Win9X PC that's not a proprietary thing. Need to order proto boards to tidy up the video output for the programmer, etc etc....
So the project will be on pause for a little bit the time to do all that... then it can resume with better working conditions....
Thank you for your help so far, and see you soon !
-
Follow retiredfeline's link and its RGB(K) pin picture.
Put programmer's drive to S1 for straight cable, then it's drive B.
For straight cable and drive A you use S2, but you must also connect drive's Mtr On pin 16 to pin 10 S0.
Drives can also be single pin selected, then you can use S0 and drive itself uses its motor as it sees necessary.
Interface also used to have terminators, but quick googling didn't do any good.
So the 3.5" drive recollection I have, with clearly user accessible slide switch with stamped positions 1 and 2, may include a selection of those terminators and so the switch is very likely something else than just simple drive selection pins connection.
Included picture is a cable from earlier mentioned scrap.
The other twist I was remembering was for hard drives.
Adrian's video has a moment where he is showing a promo board of new controller supporting 4 drives.
That is the construction that was available at the beginning of times, and before any 3.5" stuff.
There all your programmer drive's S0-3 are available and Motor On is always Motor On.
With the old style controller and straight cable, it's very possible that current PC 3.5" drives can only be used as drive B.
But that is not enough if termination is present, then one drive must be connected as PC's drive A and place it as last of the cabling, if the termination selection is, like it seems, automatic.
So in that environment a cable hack seems to be inevitable, but if that actually is the case then some drive selection and termination dongles should be already available.
-
Hi Vince,
There is a reason for the twisted floppy cable. Here's an explanation: https://www.nostalgianerd.com/why-are-floppy-cables-twisted/ So the twist is needed even if there is only one drive, A:
Thanks for a very entertaining story. Your persistence is legendary. I'm wishing you successful results.
Just watched the video, thanks for the pointer... so the twist goes to drive A not B !
... except for my programmer which works with drive set as S0 yet uses a straight cable... because well, custom FDC... so when it's custom you do bacically whatever you like...
OK thanks chaps for this ton of info. Hopefully it will slowly diffuse into my brain in the next few weeks as I am clearing / preparing the bench for Season #2 of this programmer saga.
See you then....
-
OK, I " fixed " it.... well,I unfucked it rather.... as I thought it was a FDC board issue....
... would you believe it but... it's perfectly possible to insert that board upside down, for it to slide all the way in, and you not noticing anything...
... would you believe it but.... once I put the board up side.. up... it now works much better !
So the programmer can now work the disk again, it reads it at boot no worries.
Well I mean it still fails to boot of course, we are now back to problem N-1, where it cycles between BOOT 0F error and BOOT 25 error.
However after some more experiments, paying more attention.... I think it's very possible that BOOT 0F is not a boot error per se, but merely the programmer saying "OK I am now starting to boot, I will rock that floppy for a minute and tell you what ! "... then a minute later once it's done reading the disk, it returns BOOT 25.
My gut feeling is that BOOT 25 is the only genuine error code, not BOOT 0F...
So it's quite a relief... I am now out of this floppy drive selection nightmare.... cable is fine and drive too. Programmer itself needs fixing now.
So I have just finished buttoning the programmer and old PC back up, and all that mess of serial and floppy cables scattered all over then bench and more.
Stay tuned for round #2 in a few weeks probably.
It's amazing all the things we did and achieved in the first round, in just a few days / weeks.
It started as a completely unknown black box, hopeless door stop that Google could not even find a picture of, never mind any technical info...... to where we are now.
See you soon !
-
Good, better continue with positive vibes.
I've seen an upside down VGA connector.
For PC controller I'd say that IT is the custom one and programmer's one is the standard and the real thing.
Unfortunately time has passed so much that yesterday's custom is today's new standard and the old one is just something exotic.
HxC controller side has only one Mtr On, other end has 0 and 1 shorted, DS0 is also cut and it is connected to DS2 of the other end.
It also seems that drive decorations are more from elsewhere to PC so the needed cable hack dongle is missing.
But a starting point is available.
https://www.ebay.com/itm/334686826552
Then one more for the road,
a density pin, it's complicated, so for it a drive has more jumpers.
Since 5.25" disk has no indicator the controller must do that.
So one possible direction is in, from drive's point of view.
Since 3.5" disk has an indicator the other possible direction is out.
But since both disk sizes have also cases where no information is needed the third option is no density signal.
Unfortunately interfaces can also have different density polarities.
So the last thing is positive or negative signal.
Or second last.
Since there are others than PC, there are also other interests.
So to boost own hardware sales Disk Change pin 34 wont do, its position is elsewhere.
One repositioned one there is pin 2, the density pin.
BTW,
I'm confused with the Anglo concept of floppy.
I've learned two words, limpy and cracker. -
I've "never" plugged in anything upside down
The whole floppy twist thing was suppoosed to make things easy for field service droids. They didn't have to bother changing jumpers.
Well done.
-
Seems that the floppy is HP 64k style.
More in earlier zip and source directory there.Code: [Select]0100 4c 10 b0 JMP LAB_b010
0103 56 20 31 ds "V 1.96 F "
2e 39 36
20 46 20
010c b9 b7 af a3 ds B9,B7,AF,A3 ; FHP\
0110 a9 1d LDA #0x1d
0112 8d 00 80 STA DAT_8000
0115 a9 b0 LDA #0xb0
0117 8d 01 80 STA DAT_8001
011a 4c 6e b0 JMP LAB_b06e
So 0xb000 is loading address, next part of the same section is for 0x9000.
1st area of the boot disk is 0-3k hex.
After that is the first file.Code: [Select]address
0x00000 , 75 50 72 6F 73 73 31 2E 39 36 19 03 94 AA
, uPross1.96 19 03 1994
0x0000e , 20 1E AA
, 8222?
...
0x00100 , boot code
0x00474 , end code
...
0x00580 , code continue
0x00e3c , end code
...
0x01000 , system disk loader
0x0154a , end code
, block size 0x4000 starting with checksum
0x03000 0, 2B 5D FF FF 00 00 00 00
0x07000 1, 5E 26 FF FF 01 FF FF FF
0x0b000 2, 4D AB FF FF 02 FF FF FF
0x0f000 3, DD 89 FF FF 03 FF FF FF
0x13000 4, 29 E1 FF FF 04 FF FF FF
0x17000 5, 14 83 FF FF 05 FF FF FF
0x1b000 6, 7E DB FF FF 06 FF FF FF
0x1f000 7, 75 C7 FF FF 07 FF FF FF
0x23000 8, 2C 80 FF FF 08 FF FF FF
0x27000 9, 0E 12 FF FF 09 00 00 00
0x2b000 A, FF FF FF FF 0A FF FF FF
0x2d800 A, FF FF FF FF 0A FF FF FF
0x2f000 B, AE 87 FF FF 0B FF FF FF
...
0x47000 11, 4D D0 FF FF 11 FF FF FF
0x49200 11, FF FF FF FF 11 FF FF FF
...
0x6f000 1B, C2 38 FF FF 1B FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00
, picture?
...
0x7b000 1E, 50 76 FF FF 1E 00 00 00 4C 0E 40 4C 10 40 18 60 18 60 AA AA AA AA AA
, jump, jump, return, return
, empty function?
0x7f000 1F, AE DE FF FF 1F FF FF FF
0x83000 2E, 63 76 FF FF 2E FF FF FF
0x87000 3D, B5 CC FF FF 3D FF FF FF
0x8b000 36, 42 5F FF FF 36 FF FF FF
0x8f000 , 58 7D AA AA AA AA AA AA
0x93000 , 58 7D AA AA AA AA AA AA
0x97000 , 58 7D AA AA AA AA AA AA
0x9b000 , 58 7D AA AA AA AA AA AA
0x9c000 , 58 7D AA AA AA AA AA AA -
I don't understand how you got that assembly code ?
You mean you "mounted" the system disk image file as an HP64K and had success with that reading data from it and disassembling the code ?
Well done... now just show me how to do that !
Yes there is some extremely cool stuff in that ZIP file I posted on my Google drive, the two most interesting ones of course being the two DOC files at the root of the folder : "Logiciel du ROM 5000" and "Overlay1".
These documents are more than cool, they are priceless... they are actually documents meant for internal consumption only. It's a kind of cookbook that the S/W devs at Micropross, wrote to help themselves. It summarizes the very practical, concrete things they need to do to develop programs / applications for the programmer. So it's really nuts and bolts, vintage porn. It feels like we are there in their offices, working on developing this programmer with them, incredible...
It's all in French of course, since it was for their own in house use. Littered with gigantic horrific spelling mistakes, they guy who wrote these documents clearly was illiterate, makes my eyes bleed when I read him. I feel bad for him.
Anyway, it's meant for their devs so I don't get everything it says but at least we can understand some things...
1) The H/W for the 5000 and my 3000 model is indeed 100% identical. Absolutely 100% identical. There is only one H/W.
2) However it looks like the F/W might have some differences, since it looks like they use different linking scripts to build a 3000 or 5000 object file.
3) We have massive porn in the largest of the DOC files : a detailed memory map ! Same map for the 3000/5000. We have details like the address of the registers used to set the amplitude of the various programming voltages that the programmer can generate. How cool is that. We even know what bit to toggle to turn the buzzer on and off hmmm...
4) The programmer has 1MB of memory. 512K is used as "user" RAM, that's where the user stores data it reads or writes to/from a chip.
5) The other 512K is used by the programmer. That's where it stores the programs it loads from the system disk.
6) They used a 6502 CPU emulator which can be seen on the picture above, very bulky, inserted vertically into the connector that normally hosts the programming fixture with its ZIF socket.
7) The emulator is connected to a 64K HP computer. That's what they used to write their programs, then they download them into the emulator. So you were right about the 64K HP thing. They also use a Windows machine but not sure if they use it to write code or not. Looks like they used it to translate the "absolute" object file created on the 64K HP, to some other file format which they could then write onto the system disk... using small disk utilities that they wrote themselves, which are included in the ZIP file, along with their C source files ! Told you, it's all just vintage porn.
They explain how the system disk works, how it's structured :
1) They confirm what we already thought we knew : double sided, 80 tracks per side, 16 sectors of 256 bytes (rather than 512 on a PC). So 640KB total.
2) From what I understand, it looks like there is no file system riding over that low level formatting. So no MSDOS "FAT" or any other file system that one might think of. So no point wasting time trying to mount the floppy image in Linux and hope that I could see individual files in there, edit and manipulate them... no such luck. I guess it makes sense : the 6502 CPU is not a power house and moreover has only a tiny 16KB EPROM holding its F/W. So not much room to implement a file system library... and also fit all the other stuff it needs to do obviously !
So instead it looks like the CPU reads data directly, using the tracks and sectors as its "file system", to structure / organize the data on the disk.
3) As I thought, given how small the F/W is, all the "programs" / features are stored on the system disk and loaded from there.
4) They organize the disk into a data unit they call a "MAP". A map is 4 tracks long, so 4x4KB = 16KB. So they could potentially fit 40 of them on a disk, but they only use 32 maps because well... 32x16 = 512KB which as explained earlier, is the amount of RAM they gave the CPU to work with.
5) The first 16KB on the disk are not used to store "maps"/programs. Makes sense I guess. The programmer needs to "boot" from the disk, so the start of the disk must be used to store some system information... at the very least, it must tell the programmer if the system disk is for a 3000 or a 5000 model, and what version of it.
6) You can have as many maps / programs as you want, so potentially no limit on expanding the programmers functionality. What you do is simply store these extra programs on a separate disk and you ask the user to insert it in the drive. Then you load the map into the system's 512KB memory... which obviously means you need to overwrite an existing map/program.
So you boot from the system disk, read all 32 MAPS from it, fill the 512KB of RAM with it all. Then if you want to access a program from another disk, of course you need to overwrite some other program that was previously loaded form the first disk. Constant sum game...
7) As the development of the programmer went on, they changed their mind on what map number corresponded to what program, which wreaked havoc and probably explains why not all 5000 boot disks work on all versions of the 5000 model...
So lots of cool stuff in this ZIP file indeed !
-
For disassember stuff I have an old ghidra, it support 6502.
For hex stuff I have HxD, it support different line lengths.
But even with a capable disassember reading the code is still manual labor.
Expectation is also that you're familiar with it in general, and separately for what it is meant to.
So for a newcomer it will take time, and then it take some more.
What I did was pretty straight forward, I dumped the whole boot image to ghidra.
Luckily the code is partially static so jump addresses will give away the correct location.
Unluckily I did it in wrong order and read those source codes only afterwards.
The floppy, yes, it's very primitive, no filesystem.
No names either, or different sizes, just static 0x4000 each, after the 1st one and before the reserved end.
Source directory stuff uses old INT 13h calls for floppy operations, so that must be supported if those EXEs are used.
They also swap floppy parameters, so after EXE hang you may need to boot.
-
Thanks, sounds cool, will try and play with 6502 disassemblers then...
-
Don't do what I did.
Chop the image to peaces we know are the "files" and continue from there.
Combine first section so that 0x1000-0x2fff first and 0x100-0xfff second.
Then load them to base address 0x9000.
One 6502 special,
text can be code and code can be text.
Other real mode special,
code can alter code. -
Yes... divide and conquer, sounds like plan.... except I don't know how to chop a file nor stick bits together, but I guess in Linux this must be easy once you know how to do it... as always
I guess I can use the 'dd' command to chop the file.. IF you can give it an offset... I don't know if dd can use offset or if it can only read a file from the its very beginning. I shall be investigating....
-
Oh looks like dd can do it, I just looked at available parameters, below.
Looks like it's the tool for the job.
I can indeed specify an offset when reading the image file (using the "SKIP" parameter), but also specify an offset when writing (using the " SEEK" parameter)... which is to say I can concatenate two blocks of data together : I just need to tell dd to start writing the second block to the end of the first one, that's all I think...
You can specify the block size, so 4K in my case, then just specify a number of blocks rather than actual size... how convenient.
One can even use either decimal or "binary" notation, so either say 1kB (1,000 bytes) or 1K (1,024 bytes). You can even use K/M/G/T prefixes, how practical. Hmmm... sounds good to me, long live dd !
Usage: dd [OPERAND]...
or: dd OPTION
Copy a file, converting and formatting according to the operands.
bs=BYTES read and write up to BYTES bytes at a time
cbs=BYTES convert BYTES bytes at a time
conv=CONVS convert the file as per the comma separated symbol list
count=N copy only N input blocks
ibs=BYTES read up to BYTES bytes at a time (default: 512)
if=FILE read from FILE instead of stdin
iflag=FLAGS read as per the comma separated symbol list
obs=BYTES write BYTES bytes at a time (default: 512)
of=FILE write to FILE instead of stdout
oflag=FLAGS write as per the comma separated symbol list
seek=N skip N obs-sized blocks at start of output
skip=N skip N ibs-sized blocks at start of input
status=LEVEL The LEVEL of information to print to stderr;
'none' suppresses everything but error messages,
'noxfer' suppresses the final transfer statistics,
'progress' shows periodic transfer statistics
N and BYTES may be followed by the following multiplicative suffixes:
c =1, w =2, b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024, xM =M
GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y.
-
Yes... divide and conquer, sounds like plan.... except I don't know how to chop a file nor stick bits together, but I guess in Linux this must be easy once you know how to do it... as always
I guess I can use the 'dd' command to chop the file.. IF you can give it an offset... I don't know if dd can use offset or if it can only read a file from the its very beginning. I shall be investigating....
On linux wxHexEditor is your friend
-
Thanks for the suggestion, will give it a try.
-
You must have a hex editor, without it you can't see what you can't see.
And then edition is just a copy/paste thing.
Also, leave those first checksum and file number 8 bytes there.
It seems that all of it is needed for correct positioning.
Flipped bits I must take back.
They are something to do with text but maybe not exactly it.
Some are possibly extra letters, those out of basic Latin set.
Many places have C1 C2 C2 C2 C2 C2 C2 C3 as a first text part.
Latest character sets are based on DEC Multinational, no good.
Old DOS was IBM graphics, no good either.
Maybe it's HP something, but flipped bits are >======<.
-
First two below are relocated from 0x8b000 to 0x4000.
There 0x400b and 0x400d have jump addresses in ROM when 0x400f has a jump to nowhere.
Then 0x4049 has a code modifying code example.
The latter two are from the boot section.
There 0x942a and 0x942e can easily be some text stuff.
But 0x9472 and knowledge of the use of the code is telling different, what?
(it's already around here somewhere, not far)
Seems that some sections are using illegal instruction.
Found also one JAM so maybe it's something else.
E,
seems that text is early version of Roman-8 where Ax and Bx are used for controls.Code: [Select]4008 4c 27 40 JMP LAB_4027
WORD_400b+1 XREF[1,1]: 4049(R), 404f(R)
WORD_400b
400b 68 ef dw EF68h
WORD_400d+1 XREF[1,1]: 405f(R), 4065(R)
WORD_400d
400d 5c ef dw EF5Ch
**************************************************************
* FUNCTION *
**************************************************************
undefined FUN_400f()
undefined A:1 <RETURN>
FUN_400f+1 XREF[1,4]: FUN_4301:4312(c), 404c(W),
FUN_400f+2 4052(W), 4062(W), 4068(W)
FUN_400f
400f 4c 00 00 JMP PORTACode: [Select]4049 ad 0b 40 LDA WORD_400b = EF68h
404c 8d 10 40 STA FUN_400f+1
404f ad 0c 40 LDA WORD_400b+1 = null
4052 8d 11 40 STA FUN_400f+2
Just some separation for clarity.Code: [Select]s_=60_942b XREF[1,1]: 9472(R), 9472(R)
s_.=60_942a
942a 2e 3d 36 30 ds ".=60"
s_!"#_942f XREF[1,1]: 947f(R), 947f(R)
s__!"#_942e
942e 20 21 22 23 ds " !\"#"Code: [Select]LAB_9472 XREF[1]: 947d(j)
9472 bd 2a 94 LDA s_.=60_942a,X = ".=60"
9475 cd 3d 86 CMP DAT_863d
9478 f0 05 BEQ LAB_947f
947a e8 INX
947b e0 04 CPX #0x4
947d d0 f3 BNE LAB_9472
LAB_947f XREF[1]: 9478(j)
947f bd 2e 94 LDA 0x942e,X=>s_!"#_942e+1 = "!\"#" -
Thanks for your work !
Sadly I am nowhere near being able to put that to practice.
But that's fine... that's the point of having a dedicated thread... all the info people give is safe / archived, one can always scroll back to dig out older info.
As for code being data or vice versa, I guess it's fairly easy to figure out ? I mean, if it's data, the "code" will look weird, all over the shop, but if it's actually code, I guess one should be able to recognize it.
I mean, I am hardly an assembly guru, the only assembly I wrote were a couple programs, 500 lines each tops, for school projects 25+ years ago, and it was for an Intel 8051 CPU not a 6502... but still, I have recollections... and I guess every CPU has similar instructions and similar ways of naming the mnemonics...
So looking at the code in the boot section, it looks like :
- Load some variable
- compare it with whatever
- test the result and branch
- increment something
- compare it with whatever
- test the result and branch
So looks like typical code for a loop inside another loop, no ?
-
Back in the day 6502 text code was cool.
Above text stuff can be accepted input something and 60 thing a secret special parameter.
But no, location 863d seems to be a file number and the code a renumbering thing for those late file numbers.
If you want most out of the disassembler you should include boot section and ROM to all file parts.
File part is loaded to 0x4000-0x7fff, 0x8000-8fff then is its RAM space.
But it is also jumping and calling stuff from 0x9000-0xffff.
One source directory thing in zip is blocking ROM area so it should be available somehow somewhere.