| Electronics > Repair |
| Vintage chip Programmer : " Micropross ROM 3000U " |
| << < (33/38) > >> |
| m k:
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. |
| Robert763:
I've "never" plugged in anything upside down :popcorn: 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. |
| m k:
Seems that the floppy is HP 64k style. More in earlier zip and source directory there. --- Code: --- 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 --- End code --- 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: ---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 --- End code --- |
| Vince:
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 ! >:D 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 ! 8) |
| m k:
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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |