• Please review our updated Terms and Rules here

BlackGPiB — Peripheral Emulator for GRiD Compass

V

vklachkov

New Member
Joined
Nov 2, 2024
Messages
1
Hello everyone!

I want to show the BlackGPiB emulator — an experimental emulator of a hard drive, a floppy drive, a printer, and a plotter for any GRiD Compass computer.

Right now, with this device, you can boot the system from a virtual disk, run programs, and write files. The emulator can also retransmit text for printing or commands for drawing graphics to a UDP socket. You can then send this data to CUPS, HP2XX or anywhere else you want.

Here are a few photos and video:

1762971333555.png1762971350434.png1762971401697.png


This project currently works on a Raspberry Pi. We are planning to develop a new version based on a microcontroller.

Link to the repository with the code, circuit board, and all the necessary documentation:
https://github.com/vklachkov/blackgpib

As far as I know, until today there hasn't been a single fully functional GPiB bus device emulator. I hope this thing will help bring back to life the Compass computers that didn't get a floppy drive or has died bubble memory.

This project is not only mine but also the work of other community members: Kirill @BOOtak, Anton @usernameak, @JDat, and Kirill from the Belgrade hackspace Xecut.me.
 
GRiD's peripherals are specific. Other mass storage devices not made by GRiD (HP in particular) are not detected and are not usable by CCOS or DOS.
 
NeXT said:
GRiD's peripherals are specific. Other mass storage devices not made by GRiD (HP in particular) are not detected and are not usable by CCOS or DOS.
Click to expand...

I didn't mean to imply that any of them would just work.

The point is that HP-IB and GPIB are fundamentally similar and it seems like a lot of people have been doing the same baseline work for a while...
 
Istarian said:
I didn't mean to imply that any of them would just work.

The point is that HP-IB and GPIB are fundamentally similar and it seems like a lot of people have been doing the same baseline work for a while...
Click to expand...
There are few implementation pitfalls in GRiD. By reading HB-IB standard is not enough. Devil is in details.
 
Istarian said:
The point is that HP-IB and GPIB are fundamentally similar and it seems like a lot of people have been doing the same baseline work for a while...
Click to expand...

Commodore used their own flavor of GPIB/IEEE-488 for disks, printers, and other peripherals for the Commodore PET, and there are a number of emulator solutions for that, but there’s the same problem where none of these vendors settled on a common higher-level protocol for the peripherals. So, yes, I would say it’s not really accurate to say that “fully functional GPIB emulation” is new… but a device that does it for GRiDs certainly might be.
 
This is something I always dreamed of; I have a Compass 1101 that I would love to get programs onto. It currently only has the word processor. At one point I grabbed one of those dual 3.5" HPIB drives hoping it would somehow work... I'll definitely keep an eye on this development!
 
Well, Commodore could afaik out of the box use non-Commodore printers. HP even had material for their sales people on how to sell HP plotters to PET users, IIRC with examples and whatnot.

The main difference between storage and printers though is that you rarely if ever had drivers ofor particular types of storage in user applications, while user applications had drivers for different types of printers and plotters.

In other words you could most likely connect a HP drive to a PET and run a user program for transferring files between HP formatted disks and the PET, but you couldn't use the HP drive with the LOAD/SAVE commands or for that sake the OPEN/CLOSE/GET#/PRINT#/INPUT# file I/O commands as regular files.

The major difference between Commodore and most others is that the DOS is in the Commodore drives. I.E. they are really file servers rather than drives as seen from the computers perspective. Thus there were simple "dumb" peripheral sharing devices that would just do some bus arbitration for sharing drives and printers between multiple PETs or multiple VIC20/C64/C128's. In practice these were mostly a good idea for sharing devices where you didn't have lots of files open, as the drives didn't have enough memory for more than a few open things at the same time. (In particular the save/replace (save/overwrite) on the 1541 needs every free buffer, and there are three different bugs (!!) that might cause disk corruption when using that feature).
 
MiaM said:
Well, Commodore could afaik out of the box use non-Commodore printers. HP even had material for their sales people on how to sell HP plotters to PET users, IIRC with examples and whatnot.
Click to expand...

This actually proves the point I was making: GPIB is a bus. Full stop. What GPIB was missing compared to some other busses, like for instance, USB, is a collection of "generic" higher-level peripheral protocol standards. (IE, with USB you have generic device classes like HID, Mass Storage, etc, and within each of those you have subclasses that define a set of APIs that an OS can reasonably write a "generic" driver against with the expectation that a device that identifies as one of these things will support at least this minimal functionality. There's always the option for an individual device to implement enhanced functions if targeted by a more specific driver.) HP selling plotters to Commodore PET users makes perfect sense given plotter language isn't the sort of thing you'd expect to be embedded in a computer's firmware.

As for generic text printers, well sure, Commodore supported those because "support" means little more than the printer being able to respond to the generic OPEN command at a specified device number. It takes very little glue to connect a dumb Centronics parallel printer to a GPIB port; for instance the Osborne 1's printer port is technically GPIB, but they sold centronics printer cables for it that didn't have any active components because if you're not sharing the port with other devices (which would be pretty unusual to be doing with an Osborne) you can basically just wire things so the Centronics printer responds to a transfer targeted at any device number.

I have little doubt that it would be technically feasable to, for instance, write a DOS for the PET (which you'd presumably load via cassette or place in a ROM chip you'd install in one of the PET's empty sockets) that could drive an HP disk drive that speaks the Amigo or CS/80 command sets. I can't imagine anyone ever did it, though, considering how "gold plated" expensive HP equipment was at the time. A Commodore disk drive was pretty expensive because of how overbuilt they were with the dual CPUs and all... but looking it up an 82901M dual drive cost $2,230 in 1983!!!. That's half again more than the fanciest Commodore 8050 cost on introduction in 1980, which itself was hundreds of dollars more than the 2040/4040. Seems like a pretty good reason not to bother.
 
It is good idea to split into layers GPiB singaling and management in one side, and payload data into another layer. Why GRiD out of box wont work with HP FDDs and HDD?

1) GRiD by default (stock software) have different address assignment compared to HP. This can be fine tuning by changing HP device addressed.
Also there some details on GRiD regarding EOI signalling and GRiD not usin REN signal by default.

2) Payload data format is different between GRiD software and HP. This is the biggest problem. Can be fixed by writing custom device driver for GRiD OS to talk with HP.
 
Vintage Computer Club CH said:
Hi, very interested in this project, thanks for making this possible. Any idea when the next board revision is coming?
Click to expand...
Well... Sorry, I am too busy now to work on PCB fix with two wrong wires. I also want to make pin header compatible with GRiD flat cable pigtail. Need to double or triple check pinout before proceeding. Any wishes regarding PCB? Change form factor? Move components a little bit? Fix silkscreen? Etc...

At the same time @vklachkov want to migrate form single board computer to microcontroller.

Another sneak peak news from mini chat by @vklachkov:

I have some news.

I'm ~80% done reverse engineering 2102 firmware. I don't know all the states, but the basic logic is clear. I'll publish it on GitHub with photos and schematic from @YL3AKC... I don't see the point in finishing this; I've found all what I wanted.

Along with this, I created a prototype of command for writing disks without Compass. I'll add reading and formatting capabilities a little later... This is created mostly for dumping Yuri's disk, but still.

I'm pretty close to finalizing the code for the Rust version of blackgpib for Raspberry Pi.

But I won't be switching to the Pico version right away. I have several side projects. I have a lot of tasks without blackgpib... Specifically, I need to fix two floppy disk drives so my GRiDCase 3 can be used again. Without that, I can't use it or make any progress on reversing the ISA connector, fdd's are holding me
Click to expand...
 
You must log in or register to reply here.
Back
Top