| Attachment | Size |
|---|---|
 ALA ROM Photo | 176.01 KB |
| Font inside ALA ROM | 143.2 KB |
This ROM appeared in a logic board I bought.
I can't find any info on CLSystems or the lettering ALA, but here is a PNG of the contents of 0000 thru 2048 of the ROM
Lines 1 and 2 appear to be super and sub scripted numbers etc. Line 6 appears to be graphics that if arranged correctly would put CLSYSTEMS on the screen in an enlarged decorative font.
For anyone interested, the BIN file can be downloaded from my server.
I'm not sure if it was the same "C L Systems", but there was a company back around that time fram by that name which made a library card catalog system that at least part of which ran on an Apple II.
https://ejournals.bc.edu/ojs/index.php/ital/article/viewFile/5281/4749
C L Systems, Inc, a.k.a. "CLSI" LIBS 100 Automated Circulation System.
From what I've been able to gather the system ran on a DEC LSI-11 minicomputer (a small PDP-11) and used Apple II for terminals and for things like running the systems backups.
I was able to find several references to this system when googling.
Me too with that little nugget of info. I can't quite figure out why a card catalog would need super/sub scipted numbers, except maybe as citations? In any case I think there's a connection there.
Probably makes it all a bit useless beyond archiving something that there appears to be no archive of that I can find.
Never the less dumping it was a fun exercise at the very least.
[quote=TedThompson]
Me too with that little nugget of info. I can't quite figure out why a card catalog would need super/sub scipted numbers, except maybe as citations? In any case I think there's a connection there.
Probably makes it all a bit useless beyond archiving something that there appears to be no archive of that I can find.
Never the less dumping it was a fun exercise at the very least.
[/quote]
I had to do several searches before I found the references to CL Systems.
I think it is pretty likely you are correct on why they put the sub/super scripted numbers in there I think it is probably the same CLSI and your //e mobo was used in a Library back in the day.
How did you produce that graphic of the ROM? That would be something useful to have.
I agree tht the ROM image probably isn't all that useful except for historical archive, but that is important so it should be done. If that was my //e I would do that, put that EPROM somewhere for safe keeping and then burn and install a new stock Enhanced //e imgaged EPROM. That CLSI one may not work all that well with a lot of software you may want to install.
So, there's a Hebrew ROM out there (http://www.callapple.org/soft/ap2/ROM/Hebrew_Character_ROM.zip) and in that zip is a PHP script. It's SUPER basic, and I punched it up so I can put ?in=filename&out=filename in the URL and control what I'm decoding. I've got it in a directory on my webserver. I FTP the .bin file I want to see into that folder, fire the PHP with a web browser and it makes the PNG.
I then download the PNG, use Irfanview to make it 2 color, and resize it without resampling to get the bigger image.
I also used http://tomeko.net/online_tools/hex_to_file.php?lang=en to make my continuous string of Hexadecimal bytes into a bin file when I dumped my own ROM with an Arduino Nano.
Wow, that's a real Rube Goldberg kind of process. I will take a look at the script and see if I can come up with something simpler.
Dumping a ROM is a lot easier if you have an actual programmer. The MiniPro TL866CS can be had under $50, which for me has been well worth it.
I actually have been working on a DIY programmer to handle Atmel ATF22V10 GALs. Someone built one, but unfortunately theirs requires a PC with a parallel port (not that common anymore), and is written only for not only Windows, which I don't have, but for Windows 95/98 (maybe up to XP or Vista) and using an ancient compiler (a really old version of Borland C++).
I've rewritten most of their GUI tool for Linux using C and GTK+, and worked up a design to drive a programmer over USB using an Arduino Nano to control the actual programmer. My code will all build on any modern Linux (and probably MacOSX), and the Arduino side will build with the normal Arduino IDE.
The guy who designed the original ATFBlaster (based on an earlier GALBlaster for Lattice GALs) is also working on an Arduino based solution but they are going a different direction with it, instead of having a GUI on the PC side, they are making it so you do the programming by uploading the JEDEC code to the programmer over serial to the Arduino in their design. Luckily I can borrow a lot of their code for what they've ported to Arduino. It will be interesting to have two different takes on the same idea.
Rube Goldberg yes, but also exactly $0.00 invested - ok not quite since I did buy the nano but that was over a year ago and there's been 3 sitting here with nothing to do - so why not?
Anywho, I put together a simple website to do it all now -
http://visualizer.federalproductions.com
Just upload and you get an image.
Still seems like going about it the hard way. Looking at that PHP code it is super simple. I think I can probably whip together a little Perl or Python script to run it from the command line and generate a PNG, or maybe even a little GUI app if I really get ambitious.
There is little UI in it at this point, but it does open a //e style 8k video ROM image and display it. It takes the filename on the command line and an optional "-b x" parameter to override the block pixel size for the image, the x can be 1-7. It would be pretty easy to add a menu bar and open and save/save as dialog boxes to allow picking the ROM image and saving the image. I may end up doing that sometime if I ever get around to working on one of my projects which is a multi-font hack for a //e using the game port annunciators to select between 16 images in a 27512 EPROM.
https://drive.google.com/open?id=1EyMFJZ9T6zgH7RvqM9CEvwx0Z_WMMrYL
The code is simple and crude, but you can see how easy it was to convert the PHP to Perl.
The results when you feed in an image of other than 8192 bytes in size is interesting. Particularly if you feed in a ][+ video ROM image, it displays backwards.
The ][+ ROM was made that way, or rather the ][c and ][e are reversed.
Yeah, I vaguely remember there was something different like that. But it has been too long. Anyway, if I ever decide to do anything with the code I will have to add an option to reverse the display for ][+ style ROM images. What I really need is a font editor for one of the projects I have in mind. I don't think that will be too hard to write from what I have now. I need 16 different fonts to fill up a 27512 EPROM.
Since I can not edit my original post, here, for completeness, is the result of arranging the glyphs correctly:
Screenshot 2022-02-02 122244.jpg
So, not CLSystems, but rather the initials CLSI, required placing glyph 1 over glyph 2, glyph 3 over glyph 4, and so on...
Follow Dean's posts on www.theromexchange.com or on the #romx slack channel. Quite a bit of info on this.
Here is a link t the github for my chargen2png utility.
https://github.com/softwarejanitor/chargen2png
It runs on Linux and should run on MacOS if you have the GTK libraries installed (use brew if not probably). I've never tried it on Windows since I don't have it.