Re: 264/TED/Plus4 Story

On 10/27/2011 10:54 AM, Clarke Rob (KVYD) wrote:
> Hi Bil, it would be a pleasure. You can use anything I send you as you
> see fit. I'll put together some info's and a pack of pictures and send
> them to you over the weekend. I also have a pre-production plus+4 which
> came from the same source as the 232 and a pre-prod C16 board with hand
> re-workings which came from Commodore's Corby plant in the UK. Most
> TED's and PLA's are ceramic and have EPROMS.

Oh? Could you take a look at the TEDs an post the writing on them? I'm 
curious whether those are 7360 or 8360 and what revision. Also, what 
CPUs do you have? 7501 or 8501? Ceramic?


> Could you answer a couple of questions on the TED architecture / history
> which have always bothered me? How did the economics justify designing
> and building the 7501 CPU for the TED series when the 6510 was already
> well established. Was is just because you really needed the extra two
> ports on the $01 register or was there other reasons?

The 7501 has only a 7bit port (bit 5 is missing) while the 6510 has a 
6bit port. From what I saw in the schematics is that 6 bits are not 
enough to make 1 tape and 1 IEC port, you need at least 1 bit more and 
even then you have to share one line.

If you have a C116 board, take a closer look at it, the chips with the 
U-numbers 1 to 10 seem to be the original design (when compared with the 
TED prototype board), all the others came later. That means the 
architecture was supposed to have only the I/O-port in the CPU for 
hooking up external peripherals. Yes, you had to make a new CPU, but you 
would have saved a lot of PCB space, traces and a few TTLs. It was 
supposed to be a low cost design after all.

I haven't looked at the code in detail, but having Bit 7 and Bit 6 as 
inputs makes life easier since you can use the BIT $01 command and have 
the state of both bits present in the status register (negative flag and 
overflow flag) and then just use the branch commands.

At least that's my impression from looking at the design, maybe Bil has 
some more details or corrections.


> Something else that has always niggled at me is how the TED gets reset
> when it doesn't appear to have a reset line. The two pseudo registers at
> $3E and $3F control whether RAM or ROM is visible. If the machine is
> RESET when RAM is visible, how does the CPU see the ROM's? What tells
> TED to bank the ROMS in on reset?

If you take a look at the ROM, the very first command the CPU executes 
after loading the RESET vector is STA $FF3E at $FFF6 to enable ROM, then 
a JMP $F2A4. If you switch the Monitor output to RAM (set $07F8 to $80) 
and then take a look at $FFF0 and following, you will notice that you 
find the same 2 commands and the proper reset Vector there too. Looks 
like the Kernel copies these few bytes to RAM during RESET. This way TED 
doesn't need to know if a RESET has occured. It only cost 6 Bytes of RAM 
and a few Bytes of ROM to implement while allowing a proper RESET no 
matter what state the RAM/ROM-selector in TED is in without needing a 
49th pin on TED.

This also explains why some of the games I have are reset-proof. Just 
pressing RESET won't kill them, you need to power cycle the system. They 
overwrote that piece of code with their own vector to just restart the game.

For power up, I assume that TED has a little reset circuit on die that 
makes sure that ROM is enabled by default.

  Gerrit


       Message was sent through the cbm-hackers mailing list