Nils Eilers custom character rom. Pet?

[Pet Rescue]

Hi All I can't seem to find the info on Nils Eilers custom character rom on the pet.

It used to be on 6502.org under hardware projects but the links are dead.

Has anyone got the info or a link for them?

 

[for()]

I removed this page because I made it a few years ago and have been learning since then

It was plugged into a PET ROM expansion socket and was made with two huge IDT7130 (48 pin DIP!) 1KB dual port RAMs, a 74HCT139, a 74HCT00 and a 74HCT74 plus an empty ROM socket for the expansion ROM that could also get used. Write access always addressed the character generator RAM and whether read access should address RAM or RAM was selectable by a jumper.
The user defined charset could be enabled / disabled with a POKE and of course it started with user defined charset disabled since there wouldn't be any useful character set immediately after reset.

It did some strange things with PHI2 and R/W I wouldn't repeat. That's why the page is offline. Besides that, I'd prefer a single IDT7132 (2 KB dual ported RAM, PLCC socket) and a 16V8 GAL today.

 

[Pet Rescue]

Hi for(,,) I didn't realise you and Nils are one in the same!

Was there any way to have user define the character set using that hardware the same way you alter the chartacter set on a C64 via programming!
or are the characters set burnt into the rom so can only be read not altered if you know what I mean!

If not how would it be possible by modifying the Pet to have user defined characters?

Do you still have the Fonteditor software availble?

 

[MikeS]

I'd say it depends on what you want to do and what kind of machine you have.

Just a fixed alternate character set is easy; IIRC the CRTC models provide for it, otherwise it could be switch-selectable.

I wonder why a programmable-on-the-fly version would require dual-port RAM, a GAL etc.; couldn't you just stick an NVRAM chip (or even an ordinary SRAM if you don't mind loading it every time) into a sandwich board that plugs into a spare ROM socket, a cable to the CG socket, and some MUXes selected by a PIA bit to switch between them?

 

[Pet Rescue]

Hi MikeS I have a few machines including 2001,4008,4032,8032 and 8296D

I wanted to alter the fonts and define characters to enable background graphics etc.

I remember changing full alphabet on the C64 to different font styles that were poke'd into memory.

I was looking along those lines, or are you stuck with petscii?

 

[MikeS]

Hi MikeS I have a few machines including 2001,4008,4032,8032 and 8296D

I wanted to alter the fonts and define characters to enable background graphics etc.

I remember changing full alphabet on the C64 to different font styles that were poke'd into memory.

I was looking along those lines, or are you stuck with petscii?

In a stock PET the characters are in a ROM that is indirectly accessed by the video RAM and not accessible to the PET's CPU, i.e. even if you replaced it with RAM you can't poke or peek it because it doesn't have an address. The location in the ROM and the resulting character are selected by the numerical value of the different characters on the screen as it is scanned.

There are techniques for generating different characters by 'combining' existing ones by changing the character displayed at a certain location with a different one on every alternate screen sweep, but that involves some pretty tricky timing and is quite limited.

You could certainly burn a ROM with whatever characters/fonts/symbols you like; as you probably know the stock PET has two sets of characters available containing upper and/or lower letters and/or graphics, selected by location 59468 and/or a special character in the CRTC models. You could replace the 2K chip with a 4K version which would let you select yet another two character sets, but of course not necessarily at the same time.

All these sets are burned into a ROM though, so not user-definable in real time; in order to have a truly redefinable character set you would have to be able to access the character tables both from the screen memory as usual and also from the CPU somehow (and not at the same time!), which is presumably what Nils did with the two-port memory.

Let's see if Steve G pops in here; I think he's been contemplating something along these lines as well and he'll no doubt have some corrections to my explanation ;-) ...

 

[for()]

Was there any way to have user define the character set using that hardware the same way you alter the chartacter set on a C64 via programming!
or are the characters set burnt into the rom so can only be read not altered if you know what I mean!

The character set is burnt into a ROM and thus can not get changed. Even more, at the PET it is impossible for the CPU to even read its contents. You may have a look at the CRTC block diagrams made by André Fachat, it shows that there's no connection.

If not how would it be possible by modifying the Pet to have user defined characters?

The trick is to remove the original character generator ROM. A daughter board carrying at least a RAM and some glue logic then adds the connection between CPU and CRTC. The CRTC reads out the RAM just like it did the original character generator. But the RAM is also mapped into a memory location the CPU can access. The 6502 can address only 64KB -- so where can you insert an additional 2 KB space for a complete charset without doing any harm? I voted for the expansion ROM that gets shared then: read access can just give the expansion ROM and write access can alter the character set.

Do you still have the Fonteditor software availble?

Yes, I still have it somewhere. But it requires RAM at the expansion ROM area to run and is completely useless without dedicated hardware.

I wonder why a programmable-on-the-fly version would require dual-port RAM, a GAL etc.; couldn't you just stick an NVRAM chip (or even an ordinary SRAM if you don't mind loading it every time) into a sandwich board that plugs into a spare ROM socket, a cable to the CG socket, and some MUXes selected by a PIA bit to switch between them?

It could be done this way, of course! But let's have a closer look at these "some MUXes": you have do switch the data and address lines of the character generator between the CPU and the CRTC. That's a 8 bit bus driver for the data bus (1 chip) and at least three more for the address bus (total 4 chips). Let's say 3 piece 74157 mux 12 address lines. I was lazy and didn't want to solder four more chips wire by wire if I could have a RAM that already has these MUXes built in.

Same is true for the GAL of course. It isn't a requirement, but it saves some solder work, PCB space and hence costs.

There are techniques for generating different characters by 'combining' existing ones by changing the character displayed at a certain location with a different one on every alternate screen sweep, but that involves some pretty tricky timing and is quite limited.

The timing isn't that difficult. It's just an extension to the IRQ routine.

Have been playing around with this trick last year -- WTE posted the results in his blog. But I'd say it's rather a proof of concept since it's too limited and flickers a lot. I did not replace characters, I toggled between to display contents after each frame what is only possible at the 8296. Since the two frames are overlapping and the CRT is rather slow they appear as a single picture.

 

[Pet Rescue]

What actually makes the computer look at the character rom is that the hardware?

Is it the kernal that says to the video ram look in location xxxx?

If I understand it correctly you can't just replace the rom with ram because you dont have a location to poke a value in to change that character set in that location.

 

[Eudimorphodon]

To reiterate again:

What actually makes the computer look at the character rom is that the hardware?

Is it the kernal that says to the video ram look in location xxxx?

The screen generation process is entirely in hardware. (That is why the older PETs can display a screen full of perfectly formed garbage characters even if their CPU is halted or the ROMs corrupted. The newer ones require the ROMs to intialize the piece of hardware that forms the characters, IE, the CRTC, but once it's running it's again completely "hardwired".) Basically it work like this: (Generalizing based on the original 40 column PET and oversimplifying a little.)

There are a series of binary counters. One counts to forty, for the number of characters in a line of text, and another counts to 25 for the number of lines. 40x25=1000, the total number of characters on the screen, and that explains why your PET has 1K of video RAM. That part seems easy enough to understand, right? You stick a value in a memory location and it shows up on the screen as the counter counts through the 1K of video RAM? But... wait a minute: it's not that easy. Each character is 8 scan lines tall. So you can't just read a character once and stick it up on the screen in one blow, since the video circuitry only generates one line of dots at a time. And how does it know what those dots should be?

There's another counter for the number of scan lines in each character. It counts to 8. For every line of text the scanning hardware reads 40 contiguous memory locations 8 times over; when it's done it moves on to the next 40 locations. What does that accomplish? Each character is an 8 bit binary number. The lower 7 bits, 0-127, are used directly to specify what character are displayed. The top bit, 128, specifies whether a character is displayed as "normal" or reverse video. When the value is read from the character memory that bit goes straight to a gate that controls an inverter: if that bit is set than black becomes white and vice-versa. What about the other seven bits? Well: Remember how we're counting to 8? Those seven bits are combined with the three bits (000 through 111) of the 8 count to produce an 10 bit memory address. That's how we get the 8 dots that make up a given vertical slice of a character. So:

If I understand it correctly you can't just replace the rom with ram because you dont have a location to poke a value in to change that character set in that location.

Yes. Unlike a machine that allows user-definable character tables to reside in memory space accessible on the CPU bus, that 10 bit memory address is fed into a completely private address bus that lives between the PET's character ROM and the address generation circuitry in the video hardware. The CPU cannot interviene in what happens there *at all*. Completely under control of the video hardware the ROM is fed an address generated by the combination of the binary value of the character and the scan line position, and the 8 bit data byte it returns is fed directly into a shift register which clocks the bits out to the hardware which controls whether the electron beam sweeping across the monitor lights up a spot or not. The only thing that the user can modify on a normal pet is there's a latch on the character ROM that activates or deactivates the top address line. (You may have noticed that 10 bits=1k, while a PET has a 2K character ROM. By activating or deactivating the latch you can control which half of the ROM the reads come from and therefore control which of hardcoded character sets are used when rendering.)

Thus the only way to have user generated characters on a PET is to actually modify the hardware so you can substitute a writeable memory of some sort for the Character ROM, and there follows the hardware discussion about RAMs and dual porting and MUXes, etc.

I don't have a reference for a period PET add-on that provided this capability, but there was a fairly common third-party add-on for the TRS-80 that did exactly what's being discussed:

http://www.trs-80.org/80-grafix/

(The TRS-80 Model I and III had quite similar video hardware to the PET.)

 

[MikeS]

...The only thing that the user can modify on a normal pet is there's a latch on the character ROM that activates or deactivates the top address line. (You may have noticed that 10 bits=1k, while a PET has a 2K character ROM. By activating or deactivating the latch you can control which half of the ROM the reads come from and therefore control which of hardcoded character sets are used when rendering.)

You sneaky devil; I started to reply and you'd changed the text in the meantime - very confusing ;-)

What you describe is the normal alternate character set selected by a poke to 59468, but the CRTC models do indeed have provisions for a 4K character generator ROM (as you'd originally mentioned), selected by a bit in the CRTC. I believe this was in fact implemented in some countries (Germany?) to display the local character sets (umlauts, etc.)

On the non-CRTC PETs the pin that would select the other 2K is grounded, but could easily be rerouted to a switch or even a pin on the PIA or VIA; many of us did that, either for special characters or as a 'secret code' ;-)

 

[Pet Rescue]

Thanks Eudimorphodon that was a really good explanation thank you!

It helps you understand what goes on in those chips etc.

 

[Eudimorphodon]

You sneaky devil; I started to reply and you'd changed the text in the meantime - very confusing ;-)

*snicker* It was clearly too early in the morning here when I typed that up. Need more coffee...

(It's possible I might have been vaguely recalling that some PETs had 4k character ROMs based on some unrelated casual reading and got it temporarily kerfused.)

I've idly nursed the idea of using the CHARROM socket to provide a PET with full-screen bitmapped graphics by doing something really disgusting like this:

A: Map 8K of RAM into the unused ROM socket area.

B: Provide the necessary MUX-ing to make it "dual-ported" and extract the 10 bits of address information as per a "user generated character set" design, and:

C: Use some micro clips connected to pins in the RAM address-generation circuit to move a 1k window through the provided 8k of VRAM based on the top 3 bits that's fed to the video memory during screen refresh.

Basically you'd fill the 1K of "real" screen memory with numbers 0 through 127 eight times, and each block of 128 characters would be rendered in their own custom character set. Of course, since the screen isn't an even binary number wide I can't really think of a way to shuffle the address lines to prevent the resulting "frame buffer" from being maddeningly non-linear but there are in theory some interesting tricks you could pull off thanks to the "tile mapping" of chunks of said buffer to the 40x25 grid of character spaces. (I'm fuzzy on the details but I seem to recall that the TMS9918A chip used in the ColecoVision/MSX/etc does bitmaps essentially by "tile-mapping" with multiple character sets.)

Bleah. I suppose a better solution would be to just run 13 clips to the 10 RAM address lines and the three bit row counter and use them to generate your 8k graphics RAM address, and stick a MUX between the data lines from the character ROM and the output from your graphics-RAM. Set it up so when the value in a given position is your least favorite PETSCII character it disables the character ROM output and subs the output from the GRAM. Easy text and graphics mixing on the same screen!

(Hrm. Actually, maybe you could do with fewer clips. Put your own counters on the graphics board and just watch for and count read pulses or something and reset on vertical refresh...)

 

[sjgray]

Let's see if Steve G pops in here; I think he's been contemplating something along these lines as well and he'll no doubt have some corrections to my explanation ;-) ...

Ya, I've been toying with it as well. I have started a schematic but my electronics knowledge is very basic so it's not going very fast. No time as usual.

I also thought about adding paged ram to the screen memory. You could have 16K ram directly accessable to the CRTC chip and use a LATCH to select which is visible to the CPU. Also, you could do some tricks with the character height (like is done in the "no pets allowed" demo) to create a bitmap-like screen. Using the upper 2K of a 4K character rom, you define the characters so that the byte pattern displayed matched the byte in ram then set the character height to 1 pixel (or maybe two) you could get bitmapped graphics.

The 8296 computer actually accesses main ram for it's display and can use up to 8K ram for the screen, so you wouldn't even need to add memory, just create a new character rom. Something I want to try as well.

Steve