Re: CBM720 heads up

From: Christian Dirks <>
Date: Fri, 02 Jan 2015 00:50:50 +0100
Message-ID: <>
Hi Andre,
you may take a look at
This should help you to rebuild the commodore diagnostics set for CBM
600/700 computers.
It tests DRAM, SRAM, ROM, I/O (IEEE-, tape-, user- and keyboard port)
and the SID.
The SID test has to be verified by listening. (ping-ping-ping-swoosh)
If you do not have a cartridge you may piggyback an EPROM to one of the
EPROMs on the mainboard and get the /CS line from the expansion port.

Back on terminal programs:
I tried all terminal programs for the CBM II computers I could get hold off.
Most of them were far from satisfying.
The only one which worked for me was the vt52 emulator:
Maybe you remember we had a CBM 710 running it connected to a linux box
running a text based browser in Berlin at the CC2013. You could have
seen it from your place ;).
Unfortunately, like the diagnostic software, it is made to be used as a
And it's in hungarian language, but nevertheless it's not to hard to use it.
Maybe someone will translate it and make a version that can be loaded
into RAM. ;)

Am 01.01.2015 um 23:35 schrieb A. Fachat:
> Hi there, some update and a question...
> I've replaced three dRAM chips, and the CIA used for the IEEE488 and now the 
> machine is working (even SID works). I'll update the pictures on Flickr when I 
> have more time.
> However, I'm looking for a working program to test the RS232 interface. I 
> found the (two) CBM TERM program(s) - but unfortunately I have no idea how 
> they work.
> Has anyone some more information on these terminal programs (e.g. how to 
> change baud rate etc), or another, more simple, terminal program for the 
> 600/700 machines?
> Many thanks
> André
> On Sunday 23 November 2014 18:21:42 you wrote:
>> Hi there,
>> On Sunday 02 November 2014 02:03:55 you wrote:
>>>> Unfortunately IEEE488 does not work (at least with my Arduino XD2031
>>>> setup... which probably doesn't mean much)
>>> Check the CIA and TPI chips then.
>> Unfortunately I found that it didn't even get to using the IEEE bus because
>> of memory problems.
>> It looked as if in Bank 1 Bit D5 would be flakey. Writing various patterns
>> to it suggested that when you write a 0 to it, it would not be stable.
>> Address patterns are located in various 256 byte pages of bank 1, but there
>> in the top areas under addresses 127 and 255 of each page.
>> Unfortunately replacing the corresponding memory chip did not help - same
>> error pattern with a new chip.
>> So what do you think it could be?
>> - "bank 1" is NOT what uses "/CASSEG1,RASSEG1" in the schematics? then I
>> have replaced the wrong chip (from the wrong bank)
>> - I think the data bus buffer U33 is highly unlikely. It buffers all DRAM
>> accesses and the error is specifically located
>> - One of the four 4-to-1 selectors U27,U28,U34,U35? Bit patterns of the
>> error would then suggest multiple of those
>> - MUX decoding for those selectors? would that not influence all addresses?
>> - Or the PLA U75 in the end which is supposedly known to fail? It creates
>> /CASSEG1,/RASSEG1. But why then only some of the addresses within the bank?
>> I'm baffled.
>> (see also
>> -repair )
>> Any help appreciated!
>> André
>>        Message was sent through the cbm-hackers mailing list
>        Message was sent through the cbm-hackers mailing list

Christian Dirks

       Message was sent through the cbm-hackers mailing list
Received on 2015-01-02 01:00:04

Archive generated by hypermail 2.2.0.