There have been a few versions of the utility imd2raw.c floating around
that will take Dave Dunfield's ImageDisk-created images (i.e. an .IMD file)
and make a linear binary image devoid of any metadata. This is similar to
the function of Dave's IMDU.COM program's /b switch.
I've corrected a problem with the assumption that all imd2raw.c descendants
to date have made: sectors that have a skew (i.e. not 1-1 interleaved)
weren't linearized correctly. The skewed sectors need to be written out in
"sorted" order, which is not necessarily captured/physical order. This is
easily verified by comparing output from "IMDU /b" to earlier imd2raw
outputs on any .IMD that has a sector skew that isn't 1, 2, 3 [...].
It's up on github here:
https://github.com/RetroFloppy/imd2raw
Hello,
I'm an employee with the National radio astronomy observatory here in Socorro New Mexico.
As part of our NGVLA upgrades, we are seeking to get rid of old data tapes from the tape reel days of Computing. These contain things such as the boot loaders, OS, specific collection programs and antenna movement programs.
I personally would hate to see these just wind up in the literal dumpster and would like to see them sent out to a museum or an archiving body that can preserve them and keep them safe as a dynamic part of history.
If anyone is interested or knows someone who would be interested in the VLAs data tape library please let me know.
V/R
Danielle Werts
Front end engineer
VLA Socorro New Mexico
40 years ago this year Intel came out with the 80386 – 386 – or i386.
Either seems to be correct. What this meant was a memory address of 4GB,
far beyond what an average computer user would need or want, but was so
much more than previously(8086, 80286); ‘true’ multi-tasking which for the
average computer user didn’t mean all that much; and paging, which made
virtualization possible- experimenters were over-joyed! What all this
contributed to was the end of the classical/vintage-computing era. Whether
this began the time of open-source OS development is debatable!
Happy computing?
Murray 🙂
Hi there,
at the beginning of the 90ies I've repaired some Esprit Opus220
terminals for an local computer shop. Problem #1 of those seriaal
terminals was a bad the Flyback Transformer. The Shop managed to
get a bunch of those FBT's new from Taiwan so I could successfully
repair approx 10 of those terminals. I'm still own one of them,
still in functional condition (orange 12 or 14" CRT)..
My stash of goods should still contain two of those Replacement FBT's,
but after a move in 2020 I have to locate them..
So far so good. Now the Problem:
I have an Grundig CD313 monitor from an CNC EDM Machine on the table,
the FBT Grundig 29200-003.05 is bad and I want to repair the monitor
for the small company owning that machine. Unfortunaltely they are
located some miles away from me..
My hope is to locate the two new FBTs and adapt one of them into the
Grundig CD313 Monitor..where I have the schematics for. It where pretty
nice if I could get the schematics from one of that Esprit Opus II (220)
Terminals to look at the wiring for the FBT ..and that's my problem..
has anyone the scheamtics for those Opus terminals?
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583
info(a)tsht.de Tel +49 37292 709778 Mobil: 0172 8790 741
Checking on if anyone has an old Interact system out there.
It wasn't widely successful, but gained some popularity around Ann Arbor,
MI. I've not come across one of these yet. But I've come across one of
its "Killer Application", a tape-based program called Message Center that
lets users construct banner message scripts with a few video/audio effects.
Would be interested to see this "for real" rather than just in the
MAME emulator. Or also to hear any stories about the system, such as
anyone who actually used one, or saw one being used at a storefront?
-Steve
Well, just yesterday I tested a set of RWS (RAM) replacement cards for the
IBM 5110 from Patrick Lebbard from Canada - and I'm very impressed. They
work well, I had them running for a few hours.
Details are described here:
https://voidstar.blog/ibm-5110-rws-ram-modern-make-replacements/
or VCF thread
https://forum.vcfed.org/index.php?threads/ibm-5110-ram-timings.1253087/
I don't think he plans on becoming a retailer, they've offered up the
schematic and such. But he did make these boards for me after I shipped
him a set of the base connectors that you need (to adapt them to the 5110's
A1 board) that I pulled from a known-broken board.
His motivation is that he does have a 5100 also that he's trying to
resurrect, so he plans to carry on and make an IBM 5100 version of these
modules also (still resolving a few technical differences between them, so
it's not working out just yet - but the 5110 version of these I can say
seem flawless).
Anyway, exciting stuff to see someone technically savvy enough to probe
signals and reverse engineer 50+ year old tech!
-Steve
I've been digging through CHM and bitsavers and haven't found an IMF for
5100 or 5110 yet. It seems a lot of CE material was just not saved.
However, I've been tracing execution of ExecROS and the APL ROS - thanks
to your excellent emulator and the extracted ROS files this works well.
Have learned a few things about the jump tables, I'd imagine that the
type 23 files would likely install themselves in high memory and modify
an IOCB jump entry to point to the new/patch code. Kind of like how you
take over the printer IOCB.
One little issue I found with your emulator is behavior of interrupts
while in HOLD.
Per the APL and BASIC manuals, pressing HOLD while a program is running
should pause the output (mostly so you can read the screen before output
scrolls up), and then pressing HOLD again is supposed to continue execution.
In emu5110 that didn't work, pressing HOLD always stopped but a 2nd
press wanders off in to never land (hang or bogus error or junk on screen).
While tracing & learning I noticed that if code was being executed from
one of the language ROS, HOLD would fail. But HOLD/resume worked fine
on an idle machine - idle is a short loop that just blinks the _ cursor
at location 0x0200+902 in APL.
So looking through the pseudo-schematics/block diagrams in SY31-0552-3
IBM 5110 System Logic there is quite a bit of gate logic on the multiple
ROS cards, plenty of wires between them. Maybe, hardware interrupts are
held off in hardware when we are doing reads from the language ROS
cards. The interrupt bits are properly shown in a register, but nothing
detailing gating of interrupt -> CPU.
To test the idea I made this change in emu.c:
175c175,176
< check_int(); /* check for pending interrupts */
---
>if(curr_ros==ExecROS) /* if in ExecROS we can HOLD/resume */
> check_int(); /* check for pending interrupts */
and now HOLD works as expected.
Norbert's JavaScript port had the same issue with HOLD, he ported the
above and confirmed that the HOLD now works properly.
As a side note, the MAME emulation (which may have been done
independently) has the same problem, likely could use the same fix.
Anyone know how to contact the MAME author?
There was a lot of interest in the CHM release of APL\360 source along
with auto-operator and I've tried contact a few of those folks, we just
need one CE or user who kept a box of floppies.
-Robert
