>
>Subject: Character Generator ROM data
> From: Chuck Swiger <cswiger at widomaker.com>
> Date: Fri, 21 Oct 2005 21:47:44 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Gang -
>
> Anybody know of readily available data for, say, 7x9 dot-matrix characters?
>I'm looking for a downloadable rom image for something like in old video
>cards to
>paint ascii characters on a display.
>
>For example, my Polymorphic Systems Video Terminal Interface (VTI) card uses
>an MCM6571A (or it could use a 6574) -BUT- I do not need exactly that
>font - any 7x9 data will work. Spent the past hour trying terms in
>google w/o
>anything usable turning up.
Is simple. Find a pattern you like in row or colum scan and convert the
bit pattern to a string of hex values and cook an Eprom/EEPROM.
Myself I needed a while back a 7x9 that had decenders one of the M6571
series has that so I found that data sheet. They fit easily into a 2716
or similar.
Hint where they go in rom is based on SxC IE: number of scan lines typically
11 or 12 for 7x9 fonts and the number of characters. For 7x9 CRT fonts
(ROW scanned) the low 4 addresses lines are the row data and the next 7
(128 char font) are the character address. Nothing magic.
Allison
>
>Subject: Re: OT: Tube Audio
> From: William Donzelli <aw288 at osfn.org>
> Date: Fri, 21 Oct 2005 21:39:12 -0400 (EDT)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>> I'm halfway willing to officially sanction all discussion of antique radios
>> ;)
>
>That half might get you punched in the nose.
>
>Actually, there are no good antique radio groups/lists - all are watered
>down. There is a good military radio list, however.
>
>William Donzelli
>aw288 at osfn.org
>
That and we reaching the point where computers and radios that contain
or are married to them are over 10 years old (some a whole lot older,
think Pioneer).
Allison
stevew <stevew at ka6s.com> wrote:
> There is a program called Veritakwin running on Windows that is $50 and is
> many times faster (4-5X) than Icarus.
If it's for Winblows, why are you even telling me about it? It is illegal
to bring a Winblows machine across the threshold of my house.
> It is a windowed environment and has a built in wave-form viewer.
I don't want a windowed environment or a waveform viewer, I want to do
all my development from an ASR33! That's why I love Icarus Verilog, it
is 100% command line. Although unfortunately it wants "modern UNIX" and
won't build under 4.3BSD (written in C++ for a start), since it's
command line I can have it running on my Linux box and use it from my
main development VAX via rsh.
> Second - the Xilinx tool is running native on Linux but is a bit flakey for
> 6.0.
OK, that's good to know.
> What I don't understand is - Why not use the Synthesis tool in Webpack as
> well? Why even BOTHER with Icarus for this part of the tool chain?
Because I want to, for religious reasons.
> It isn't as good as Synplify - but it DOES work most of the time??????
I don't want a good tool, I want a free one (free as in speech). Freedom
is more important than quality to me. I'll gladly settle for a design
that requires a 10 times larger FPGA than necessary and has a 10 times
lower maximum clock speed if it can be done with free-as-in-speech tools.
> Good luck with your project.
>
> Steve Wilson (Professional Verilog slinger)
Thanks,
MS, religious zealot, evangelist of Free Software and command line environment.
On Thu, 20 Oct 2005, charlesmorris at direcway.com wrote:
> Now that I have an apparently functioning PDP-8/A with 16K of core, and
> (hopefully soon) a working RL02, I am wondering what operating system
> would be appropriate. Currently I don't have any other input device
> aside from the programmer's panel and the keyboard, so naturally I need
> something that can be booted from an RL02...
>
> Any recommendations? Will software written for, say, an 8/E or 8/I run
> on an 8/A without patching?
> Could I run OS/8? TSS/8? Many years ago I used to have access to a TTY
> timeshared to an 8/E running Edusystem 50 (TSS/8) and would like that
> "feel" again...
The only OSes I know of that supports the RL8A is OS/8 and RTS-8. For
OS/8, one RL02 will look like five disks (it's huge! :-) ).
Yes, as far as software is concerned, most everything written for an 8/I
or 8/E will also run on an 8/A.
I say most, since there are some incompatibilties that could bite you. But
then you're playing with undocumented opcodes, or hardware that is
optional.
However, the 8/E and 8/A are *very* similar. In fact, some 8/A systems had
the KK8E CPU in them.
Things that are incompatible, as far as I can remember offhand right now:
BSW instruction exists only on 8/E and 8/A.
MQ register exists always on 8/E and 8/A, but only exists on 8/I if you
have EAE. The 8/A cannot have an EAE. The EAE of the 8/E can run in two
modes, where one is compatible with the EAE of the 8/I.
If you execute a RAR RAL, you'll get different results depending on CPU. I
don't remember exactly what the 8/I does, but the 8/E will load the AC
with the PC for the high five bits, while the low seven will be fixed
(can't remember the exact value). The 8/A will load the AC with the PC.
But since all this stuff is things most programs don't do, it should not
bite you. (I know that KERMIT-12 uses these tricks to decide what kind of
CPU you actually are running on.)
Since RTS-8 is a bit magic, in addition to being a bit hard to get
perhaps, I'd say you should go with OS/8.
RTS-8 uses OS/8 for the interactive work anyhow, so you won't get much
extra fun out of it, unless you're really starting to write some special
software.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Saturday 22 October 2005 11:37 pm, cctalk-request at classiccmp.org wrote:
>From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
>Subject: FPGA VAX update
>To: cctalk at classiccmp.org
>Message-ID: <0510230037.AA21104 at ivan.Harhan.ORG>
>Hello fellow ClassicCmp'ers,
Stuff deleted -
>I'll be using Icarus to compile Verilog to EDIF. I have heard sermons
>from "paid professional" chip designers working on the dark side (making
>non-free designs with non-free tools) about how inferior it is compared
>to whatever non-free shit they use, but I don't care, freedom is more
>important to me than quality. (And I mean free as in speech, not as in
>beer.)
Michael,
First of all - I love Icarus (I must - I organized and wrote the test suite
for it ;-) and I use it for module level stuff at home before I import to the
professional tools BUT there is another option for simulation.
There is a program called Veritakwin running on Windows that is $50 and is
many times faster (4-5X) than Icarus. It is a windowed environment and has a
built in wave-form viewer. Think Mentor modelsim like. You might think about
it as a verilog too. The implementation is more complete than Icarus and also
faster.
>The problem is of course with place & route and the actual FPGA bitstream
>or SOF (SRAM object file) generation. The first part of the problem is
>that the fucking FPGA vendors won't give us a complete description of
>the FPGA routing fabric and bitstream/SOF format. The second part of
>the problem is that even if this information were pried out or reverse-
>engineered, someone would still have to write an open source P&R tool,
>which is a *major* task - certainly not for me, designing a VAX CPU is
>enough work for me, I don't need the extra task of developing an FPGA
>P&R tool.
There are only two practical choices when it comes to the actual target
FPGA: A or X, which of course stand for Altera and Xilinx. I would be
content with either if I could work out a usable toolchain for it that
would take me from EDIF (Icarus Verilog output) to the SOF or bitstream
file (A/X respective terminology).
To make the long story short, there are two specific areas where I could
use help from other listmembers:
>1. The Xilinx option. The maintainer of Icarus Verilog only has
>experience with Xilinx. He uses X's proprietary P&R tools, but they are
>command line tools and are available for Solaris and Linux in addition
>to Losedows. (I still can't figure out whether the Xilinx-blessed Linux
>version is truly native or runs through WINE.) Icarus documentation
>includes a complete worked-out example of a build starting from Verilog
>and ending in a bitstream, feeding iverilog output (EDIF) to the command
>line tools from X's proprietary software.
First - Steve Williams uses this path on a daily basis for his day job, so it
is a proven path.
Second - the Xilinx tool is running native on Linux but is a bit flakey for
6.0.
What I don't understand is - Why not use the Synthesis tool in Webpack as
well? Why even BOTHER with Icarus for this part of the tool chain? It isn't
as good as Synplify - but it DOES work most of the time??????
>Since this might be a workable option for me, does anyone here have the
>Xilinx Foundation tools installed on a Solaris or Linux box on which I
>could get an account for work on my FPGA VAX project?
The Windows version is faster than the Solaris version. I believe the lInux
version is faster than either...though that is from a very faulty memory.
If I were setting up for a private (home) project with FPGAs today I would
choose Veritakwin and Webpack as my tool chain. I get MUCH faster
simulations, and a working synthesis/P&R tool in Webpack. (I've really never
figured out why Steve bothered to do the Synthesis tool beyond the challenge
of it...maybe that's the answer..)
Good luck with your project.
Steve Wilson (Professional Verilog slinger)
Answering my own post:
> all from Xilinx. After competing with NeoCad for a few years Xilinx bought
> them in 1995 and used the NeoCad tools.
I looked up some more facts. NeoCad was founded in November 1991 and had
about 50 employees when it was sold to Xilinx in March 1995 for $35 million.
The large FPGAs back then were pushing 10,000 gates.
Michael Holley
www.swtpc.com/mholley
Gang -
Anybody know of readily available data for, say, 7x9 dot-matrix characters?
I'm looking for a downloadable rom image for something like in old video
cards to
paint ascii characters on a display.
For example, my Polymorphic Systems Video Terminal Interface (VTI) card uses
an MCM6571A (or it could use a 6574) -BUT- I do not need exactly that
font - any 7x9 data will work. Spent the past hour trying terms in
google w/o
anything usable turning up.
******* ***** *
* * * *
* * * *
* * ******
* * * *
* * * *
* * * *
* * * *
* ***** * *
--Chuck
Hello fellow ClassicCmp'ers,
I have made it known in the past that I have interest in designing and
building a new CPU chip implementing the VAX architecture (just as DEC
would have made a new implementation of the arch from the spec, not a
clone of any particular past implementation), and since I don't have the
$$$ to fab a real chip, it'll be a "soft chip" in an FPGA at first.
This project has been on my mind for a long time, mostly far on the back
burner, but some other life circumstances have recently dragged me once
again into the fun world of FPGAs and HDL coding (I'm doing a consulting
job that involves lots of FPGA work), and this circumstance has brought
my FPGA VAX project back closer to the front of my mind.
Obviously there are tons of issues involved in a project of such ambition,
and I don't want to bore you all to death talking about all of them, but
the one issue that I have a difficult time solving on my own is that of
FPGA tools.
I'll be using Icarus to compile Verilog to EDIF. I have heard sermons
>from "paid professional" chip designers working on the dark side (making
non-free designs with non-free tools) about how inferior it is compared
to whatever non-free shit they use, but I don't care, freedom is more
important to me than quality. (And I mean free as in speech, not as in
beer.)
The problem is of course with place & route and the actual FPGA bitstream
or SOF (SRAM object file) generation. The first part of the problem is
that the fucking FPGA vendors won't give us a complete description of
the FPGA routing fabric and bitstream/SOF format. The second part of
the problem is that even if this information were pried out or reverse-
engineered, someone would still have to write an open source P&R tool,
which is a *major* task - certainly not for me, designing a VAX CPU is
enough work for me, I don't need the extra task of developing an FPGA
P&R tool.
There are only two practical choices when it comes to the actual target
FPGA: A or X, which of course stand for Altera and Xilinx. I would be
content with either if I could work out a usable toolchain for it that
would take me from EDIF (Icarus Verilog output) to the SOF or bitstream
file (A/X respective terminology).
To make the long story short, there are two specific areas where I could
use help from other listmembers:
1. The Xilinx option. The maintainer of Icarus Verilog only has
experience with Xilinx. He uses X's proprietary P&R tools, but they are
command line tools and are available for Solaris and Linux in addition
to Losedows. (I still can't figure out whether the Xilinx-blessed Linux
version is truly native or runs through WINE.) Icarus documentation
includes a complete worked-out example of a build starting from Verilog
and ending in a bitstream, feeding iverilog output (EDIF) to the command
line tools from X's proprietary software.
Since this might be a workable option for me, does anyone here have the
Xilinx Foundation tools installed on a Solaris or Linux box on which I
could get an account for work on my FPGA VAX project?
2. The Altera option. The company for which I'm currently doing the
consulting project that brought me back into the FPGA world uses Altera,
so I have an Altera FPGA dev board and their fucking Quartus II software.
I still haven't figured out whether there is any way to use the latter
without the GUI, however, and I only have the Losedows version currently
and WINE isn't exactly my cup of tea. So I don't know if I'll be able
to shoehorn Quartus into a backend for Icarus Verilog like the good
maintainer did with Xilinx Foundation.
However, one coworker tells me that he has seen an open source project
that apparently reverse-engineered A's SOF format and can make an SOF
>from scratch using only open source tools. Needless to say, hearing
that made me salivate. The problem is, however, that this guy (my
coworker) does not remember the project name, much less its home page,
and I have looked for it without success both on the major open source
hardware sites and with Google. The feat sounds so incredible that it
may just be too good to be true. My coworker said that he'll look for
it on his Linux box at home. But barring that, has anyone else heard of
this project?
TIA for any help,
MS
I reverse engineered some Altera PLDs (EP600 and EP900) around 1990 and that
took a few weeks. I knew some folks at NeoCad that reverse engineered the
Xilinx family and made better design tools than Xilinx. They got no help at
all from Xilinx. After competing with NeoCad for a few years Xilinx bought
them in 1995 and used the NeoCad tools.
The parts today are much larger than they were in 1995 and it took a large
group to reverse engineer the parts then. Another problem is that Xilinx
keeps developing new devices so you have a moving target.
Xilinx has a free version (ISE WebPACK) that supports the smaller FPGAs on
Windows and Red Hat Linux. The scope of the problem and the availability of
free software is going to make it difficult to get enough people to tackle
the problem. It happened before but they sold out for the big bucks.
Michael Holley
www.swtpc.com/mholley
Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
> Graham Toal wrote:
> Now that's interesting. Having seen some of Acorn's internal source and
> the way they often worked, it seemed there was a lot of "just go ahead
> and do it" philosophy going on. Maybe someone mentioned 32000 Xenix in
> passing and then some other programmer took it upon themselves to add
> support in to the linker :)
The only programmer was Mark Taunton (also Ex Edinburgh, hence why the linker
was written in Imp, and also why the link format had a lot in common with
that of EMAS!). I think he may still be working for ARM somewhere. I bet
he'd remember. I had a listing of it because I was the only other Imp
programmer there and I was helping find a storage bug that was causing
link errors for some program of mine. (The listing has a few of my
annotations).
> Again, I'll check that I don't have it on disk when I get home in a month...
It was written in Imp. I'm sure you'd remember if you'd seen it!
> > The Edinburgh collection is getting quite impressive. We also have
> > recovered locally written operating systems for the PDP9 and PDP15,
> > two O/Ses for PDP11s, Perkin Elmer 32bit, 68000s and of course the
> > big one, EMAS for ICL29XX
>
> That last one caught my eye, given that we have an ICL 2966 which we'd
> like to (try to) get operational one day (no mean feat, given how
> dismantled, rusty, and spread all to hell and back across lots of
> storerooms it is at the moment!).
>
> Seems like there are "lots" (as in more than one :) of people/places who
> know about the 1900 line, but the 29xx's seem to be largely forgotten.
> Of course a complete 1900 would be nice, but I doubt there are any left
> anywhere...
Who is 'we' in this context? I can't imagine anyone just happening to
have an ICL mainframe lying around, never mind the power to run it or
the manpower to put it all back together again!
(Hold on a sec... quick visit to Google... aha! so you're the
curator at Bletchley Park! That explains a lot :-) Hadn't seen
your Retrobeep site before! If I were still in the UK, I'd be happy
to drop by with a shitload of Acorn hardware I grabbed before it headed
for the dumpster)
So yes, it would be fantastic to get EMAS on line again, and if your
hardware works, it's definitely doable because the 2900 EMAS is the
only one we actually have full binaries for! And the University
has pretty complete archives on a CD jukebox where we could go fetch
any binaries that we're missing.
What's especially lucky is that we have a boot tape, which you're
welcome to download and see how far it gets you:
http://history.dcs.ed.ac.uk/archive/os/emas/emas2/boottape/
We have several people on the history project who might be
interested in a project like this; If you think you might be serious,
I would encourage you to join our mailing list and tell folks what
you're thinking of and ask for volunters. Some are retired; two
unfortunately work in the US. I'll put together a list of the
people who would be relevant to this and we can contact them
individually if you decide to start up a project. I would lay odds
that if you could get funding and it became obvious that it was a
serious project, we could get help from Edinburgh University (EUCS
which used to be called ERCC) and pull in a lot more folks than just
the ones already in the History Group.
We don't have binaries for either the ICL4/75 version or any of the
later IBM mainframe (or NEC/Fujistsu/Hitachi clone) versions, so although
emulators exist for the IBM (Hercules), there would have been a major
bootstrapping problem in cross-compiling the sources to IBM binaries.
And although we had ICL2900 binaries, we have no ICL2900 emulator.
It never occurred to me that we might find 2900 hardware somewhere. This
could be a major break for our project if you decide to run with it
and the hardware can be made serviceable. Also a working system would
be the perfect place to start from to write a 2900 emulator.
The biggest obstacle that I can think of would be building a disk
image with all the relevant files on it. We have them as individual
files, not as a disk image. But we have *major* amounts of source
code and even an Imp compiler, so we ought to be able to hack the
disk drivers around and create a user-level program to build a disk
image...
Incidentally, I discovered an ICL engineer on the net today, who worked
on the EMAS hardware:
http://www.whiteheadm.co.uk/html/30_years_in_computing.html
- I'll be dropping him an email this evening to tell him about the
Edinburgh project. If you start up a 2900 project, he sounds like
someone well worth speaking to.
Let's talk more about this, either here or offline, or preferably
on the Edinburgh group at
http://groups.yahoo.com/group/edinburgh-computer-history/
Regards,
Graham
PS Does Bletchley have any systems that can read DECtapes? We still
have a few tapes in our project from the PDP9 and others which we've
never read back in. Including one for an operating system called
"DECsys" which I believe some of the guys on this list are desperate
to see!
