Hi Andre, you may take a look at http://www.idealine.info/CBM/CBM_600-700_DIAG.zip 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: http://zimmers.net/anonftp/pub/cbm/b/vt52emu.bin 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 cartridge. 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. >> >> https://www.flickr.com/photos/afachat/sets/72157647798386959/ >> >> (see also >> http://www.vintage-computer.com/vcforum/showthread.php?45083-Commodore-B720 >> -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 Toast_r@Idealine.info Message was sent through the cbm-hackers mailing listReceived on 2015-01-02 01:00:04
Archive generated by hypermail 2.2.0.