The system seems to be based around an input and an output buffer for some reason I have the number 192 or 196 as size in mind.
191, to be exact ![]()
Bitte melde dich an, um diesen Anhang zu sehen.
The system seems to be based around an input and an output buffer for some reason I have the number 192 or 196 as size in mind.
191, to be exact ![]()
Bitte melde dich an, um diesen Anhang zu sehen.
First step done
Now we need some keyboard input. Display isn’t yet perfect and needs some fixes but it works
System starts from disk without any errors.
On GitHub I updated files to same version as mine.
Even cursor is blinking somehow 🤔 I didn’t expect that but wow.
Great job. So, if I understand it correctly, the only modification is the IO driver and you have set up your kim's memory map to match that of the MTU-130 bank 0, correct?
The CODOS nucleus consists of approximately 4,000 lines of assembly code, of which I have documented about 1,650. The command processor adds over 730 additional lines, with more than 420 commented, including details on how internal commands and overlays are processed.
The overlays (commands loaded into memory as needed) consist of approximately 170 lines each, with 16 overlays in total. I have documented just over 100 lines of these so far.
I have not yet started documenting the SVC processor.
To boot CODOS to a prompt on a KIM-1, you will need at least a significant portion of the nucleus and the command processor, along with either a basic TTY-based I/O driver or the full-screen driver you are analyzing.
I strongly doubt it is possible to boot a modified binary floppy image on a KIM-1 by simply poking values into system variables. That said, there’s no risk of damaging a KIM-1, so there’s no harm in trying!
Once the documented disassembly of the nucleus and command processor is complete (or nearly complete), creating a KIM-1 version that matches the CODOS 1.0 manual will be straightforward. However, making it truly useful is another matter, as the basic utilities constitute a substantial code base.
1E should be on 96 TPI.
McGyver , it may be that you have it configured for 48 TPI and that's why it tries to go further in.
For other drives BX is named dual speed instead of double speed, that does make more sense.
I would try leaving it unset first that should give 360 RPM.
Yes, leave at 360. 300 RPM will give you more capacity, which is not needed, but may cause problems with some media.
If Controller does not deliver a Mode Signal set it to PH OFF, NH, OFF and 1M ON.
The K-1013 most certainly doesn't
I saw that. In first manual you have settings on schematic. But I’m not sure which should be changed for K-1013 instead stock ones
The relevant part is this bit (the rest are usually the default for most drives):
Bitte melde dich an, um diesen Anhang zu sehen.
Also, the spindle motor should be continuosly energized or when door lever is closed.
EDIT: And drive select to 1 (if jumpers are labeled from 1 to 4) or 0 (if they are numbered 0 to 3)
I've recovered CODOS.Z from the 1.1 MULTI-O distribution disk and it is identical to the 1.5 one.
I'm making a lot of progress with the reverse-engineering and I'm starting to think that a recreation of CODOS 1 for the KIM is possible and not so far away ![]()
Alles anzeigenAlles anzeigenSome significant progress in the CODOS 2 reverse engineering effort. Still a long way to go, but I have a source file that assembles into versions 1.4, 1.5 and 1.7 of CODOS 2 and generates the CODOS.Z files, which are binary identical to the originals.
Also a fair amount of code identified and commented.
Everything at Bitte melde dich an, um diesen Link zu sehen..
That is amazing!
Why did you choose Version 1.5 over 1.7 as default?
Because I started with 1.5 and then added the other versions
Anyway, it is only formally default, as the code generates all versions.
EDIT: I'll also add version 1.1 if I can extract the CODOS.Z file from the corrupted image file.
As you address this image how much could your tool extract?
Are there any interesting file in it? Beside an very outdated version of codos?
Almost nothing. It does not seems to have anything interesting though, same file names as in other images.
Some significant progress in the CODOS 2 reverse engineering effort. Still a long way to go, but I have a source file that assembles into versions 1.4, 1.5 and 1.7 of CODOS 2 and generates the CODOS.Z files, which are binary identical to the originals.
Also a fair amount of code identified and commented.
Everything at Bitte melde dich an, um diesen Link zu sehen..
That is amazing!
Why did you choose Version 1.5 over 1.7 as default?
Because I started with 1.5 and then added the other versions ![]()
Anyway, it is only formally default, as the code generates all versions.
EDIT: I'll also add version 1.1 if I can extract the CODOS.Z file from the corrupted image file.
Some significant progress in the CODOS 2 reverse engineering effort. Still a long way to go, but I have a source file that assembles into versions 1.4, 1.5 and 1.7 of CODOS 2 and generates the CODOS.Z files, which are binary identical to the originals.
Also a fair amount of code identified and commented.
Everything at Bitte melde dich an, um diesen Link zu sehen..
The Mitsumi D359M3 is almost everywhere and is very cheap, about 5 € in decent condition. It uses the NCL039 controller, that provides a true RDY signal on PIN4, as user "judeware" documented on this post in a Czech forum: Bitte melde dich an, um diesen Link zu sehen.
In the Mitsumi D359M3, that signal is available at the marked pad (and adjacent via) in the image:
Bitte melde dich an, um diesen Anhang zu sehen.
Then, it is a matter of cutting the lines that go to pins 33 and 34, solder a wire from the marked pad to pin 34 and solder together pins 31 and 33.
Alles anzeigenCODOS in Drive 0
MULTIO in Drive 1
System starts
DIR *:1 shows corrupted output
FILES 1 shows everything fine.
I get the feeling the directory doe not fit to the rest of the disk. If you use DIR file headers get used. While FILES uses the directory blocks only.
That does not look like a simple read error while dumping more that someone combined not matching images.
On a second view there seem to be quite some sectors that are zeroed.
Some (most) of the files are misplaced, starting some sectors ahead of the block start where they should be.
I've uploaded the codosdsk utility to Bitte melde dich an, um diesen Link zu sehen.. Still missing the overlay extraction and an option to use the second BAT copy in case the first is damaged. Also working on the other utilities to convert CODOS ASCII to *nix ASCII and to inspect loadable files.
While testing the codosdsk util, I've discovered that the "Distribution Disk 1.1 - 1983 MULTI-O.imd" image and its clones, "MULTI-O 1.1.imd" and MAME's "Distribution_Disk_1.1_-_1983_MULTI-O.imd" are corrupted. Maybe it is possible to recover something or even all of it but I haven't tried yet.
I don't know how useful that would be but could you add an option that also extracts the 64 Byte Header and saves that to a separate file best as text file and ideally interpret the information we know like name, date, size load address, exec address and what is left as hex dump?
It doesn't have a lot of information, only the dir entry, file size and creation date, and the last two are shown in the DIR listing.
The load and exec addresses are in the loadable file headers (inside the file itself) and will be inspected and extracted by the work-in-progress "codosfile" utility.
More progress:
Bitte melde dich an, um diesen Anhang zu sehen.
So, now I can dir and extract any file from an IMD CODOS image. The util supports file patterns.
Before uploading to GitHub I have to clean it up, the code is a bit of a mess.
Also two more utilities in the making:
Indeed with debugging there’s a lot more useful informations
And even demos are working. Can we convert that imd into something hfe or whatever Which works on Gotek 🤔
You can use the Bitte melde dich an, um diesen Link zu sehen.. Just load the IMD images and export them as HFE.
EDIT: attached MTU-130 ROM pack for mame which includes the two 4 bit PROMs
Last one is the boot prom for the K-1013
Indeed. The KIM-1 Simulator does not support the K-1013. I have no plans to add this.
It would be already the base for an MTU-120/130 simulator.
BTW is that known: Bitte melde dich an, um diesen Link zu sehen.
Yes. The nice thing is that there is also MTU-130 support in MAME, including K-1013 emulation, so it would be almost trivial (for someone familiar with MAME) to add K-1013 emulation to the KIM-1 as well.
As there are only this 10 files I would have been to lazy to implement that.
I just had to adapt the code I already wrote for the programmable card, so the effort was small ![]()