![]() |
|
![]() |
|
|
#21 |
|
Nonode
Join Date: May 2012
Location: Perth, Scotland
Posts: 2,446
|
Interestingly, there's no white sockets on here, just black ones. And very few overall - of the 40 pin chips for example, only the 6502 was socketed.
Just found some 40 pin sockets. I'll try the 6502 first. Colin. |
|
|
|
|
#22 |
|
Nonode
Join Date: May 2012
Location: Perth, Scotland
Posts: 2,446
|
OK - we now have a consistent noise (not a chirp) and the Tynemouth diagnostics start but the screen is all over the place.
This one's going to fight again isn't it. COlin. |
|
|
|
|
#23 |
|
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 13,872
|
Oh, it's a good one. Interesting that the first line is almost perfectly formed except for being shifted one character to the left so the 'T' of Tynemouth is lost, also the word 'calculating' near the bottom is intact.
I wonder if this is the machine writing to the video RAM OK (ish) but not reading back from the video RAM properly, so screen content which doesn't get read back and written again looks more or less OK but anything which is read back from the screen, modified and being written back to the screen RAM is being 'damaged' during the read process. Just a theory. Your 'consistent noise', is this happening specifically when you boot under control of the Tynemouth Diagnostic widget? I take it when you do that in a working machine which has the Piezo sounder inbuilt, you don't get that effect? I'm assuming Daver's test code doesn't run at all. Bear in mind that for that to work the system has to be able to execute a little bit of code in the Kernel ROM briefly first before jumping into whatever is in the EDIT ROM, socket, so the original Kernel ROM has to be present in its correct socket and of course working / not corrupt. It might be worth reading and verifying the Kernel ROM's checksum against the known correct value, and once you're set up for that you might as well checksum the others as well. I'm assuming the ROMs are in sockets, which means they probably aren't. |
|
|
|
|
#24 |
|
Nonode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 2,878
|
From looking at that screenshot, it struck me that the main RAM / ROM must be OK for the program to run and display this.
So I'm thinking the main suspect would be the Video RAM / addressing buffers to these Or possibly the Character Generator ROM (Although I believe a new EPROM had just been created for this, that I assume is fully-compatible and doesn't have any extra address-lines etc that could be floating?), if certain characters are always corrupt, rather than certain positions. I presume the screen-image is consistent each time, and doesn't differ which could indicate an intermittent problem like dodgy IC sockets? (Even if not the notorious White-coloured ones, as it seems you'd already found). Although I did notice there seemed to be a bit of an odd offset, which could indicate read & write address weren't the same. Although if lowest A0 address line was stuck, you'd expect to get repeating characters / alternate gaps in the display. Last edited by ortek_service; 12th Apr 2025 at 10:11 am. |
|
|
|
|
#25 |
|
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 13,872
|
I don't know the Tynemouth device too well but I expect it uses its own onboard ROM and RAM in order to be able to test all aspects of the system without disrupting its own operation. No doubt Colin can enlighten us. Also - no white sockets, in fact not many sockets at all, in this machine.
|
|
|
|
|
#26 |
|
Nonode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 2,878
|
Yes, I recall the Tynemouth board does have its own (selectable?) on-board RAM & ROM. But I don't think this plugged into the 6502 socket (not if just a memory replacement board?) so I didn't think this bypassed the PET's multiple buffers.
Yes I had noticed this board didn't have white-coloured IC-sockets. But I also recalled Colin finding that the 6502 socket (one of only two IC sockets?) appeared to be a bit intermittent, so was replacing it. |
|
|
|
|
#27 |
|
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 13,872
|
I think we may be talking about two different things here - there is the well known 'Tynemouth Board' which is a ROM / RAM replacement board like the similar 'Romulator', but Colin was (I believe) referring to another gadget, the Tynemouth 'diagnostic' set which he also has.
But even the 'Tynemouth Board' does, I think, plug into the CPU socket and then the CPU plugs into that. |
|
|
|
|
#28 |
|
Nonode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 2,878
|
I do recall seeing ones that plugged into the RAM sockets on some PET's.
But with so many versions of the PET's board (And RAM's not always socketed - Usually only on the original Non-JEDEC pinout MOS ones), then plugging into the 6502 does make more-sense for a more-universal board. And 6502 is probably much more likely to be socketed. (Some Sideways-RAM/ROM expansion boards on the Beeb, also plugged into the 6502 socket, to get at all the required signals more-easily. Or even 'Turbo' it to 4MHz CPU speed, with faster-RAM to suit). |
|
|
|
|
#29 |
|
Nonode
Join Date: May 2012
Location: Perth, Scotland
Posts: 2,446
|
Apologies - I wasn't clear; this is the Tynemouth device I am using.
http://blog.tynemouthsoftware.co.uk/2016/07/pet-diagnostics.html Progress update is that I'm working my way through all the 40 pin devices and removing everything uneccesary (I've just left the CRTC chip and the Tynemouth board in place for now). I will also replace the character ROM old socket and all of the normal ROM chips which I notice have been replaced in the past but without sockets. COlin. Last edited by ScottishColin; 13th Apr 2025 at 4:19 pm. |
|
|
|
|
#30 |
|
Nonode
Join Date: May 2012
Location: Perth, Scotland
Posts: 2,446
|
As a matter of interest I tried the Tynemouth ROM/RAM replacement board and got the attached screen which is at least consistent with the characters being moved over by one on each line. If I change the DIP switch settings to run the on-board tester (which I belive to be an early version of the testing software) I get the checkboard pattern which at least seems to have the full 40x25 screen full of checkboard characters and perhps not shifted but that's a bit tricky to be sure about.
Suggestions regarding where to start with the video subsystem are welcomed. As another matter of interest, I tried the Romulator to do the same thing and the PET will not boot at all with that installed which I find strange. Colin. |
|
|
|
|
#31 |
|
Nonode
Join Date: May 2012
Location: Perth, Scotland
Posts: 2,446
|
As yet another matter of interest, this PET thread had the same symptoms but I can't see any conclusion to the issue.
https://forum.vcfed.org/index.php?threads/pet-4032-with-shifted-video.42217/#post-516197 Colin. |
|
|
|
|
#32 | |
|
Nonode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 2,878
|
Quote:
- It just needs working screen RAM / access-buffers and video circuitry to give an output. So it's a bit like the old Dataman Microdoc or Polar B2000 Bus Tester, that also replaced the CPU (via one of several different pin-mapping 'Personality Module' plug-in boards to support most 8bit CPU's). - Although these had a built-in thermal printer, to display results, so didn't need the target computer's display to work, in order to show results of accessing the memory in that. |
|
|
|
|
|
#33 | ||
|
Nonode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 2,878
|
Quote:
Quote:
I do notice this is all in lower-case, which looks a little odd (Although I can't recall exactly what it should normally be - All upper-case?). So this may give some clues. I also see that the 'r' in front of 'eady' is on the end of the line before, which does rather confirm some odd shift of the display addresses. The checkerboard pattern does rather indicate that the display RAM is OK. Although an inverse of this / all green + all black displays would help confirm this. - As would trying to be able to make-out what the Tynemouth diagnostic 6502 replacement is actually trying to display And the same with the ROM Tests, although it looks like these are mostly OK, if it gets as far as a ready prompt. But having these socketed probably isn't a bad idea, to rule them out / make future faults easier to track-down. Does it respond to keypresses (assuming keyboard is OK / you can patch in a working one) at that point? - I'm wondering if you could see if certain characters do not appear or whether is is just certain columns at fault? There were some IC's suggested in that vcfed link, so if you've got some spares / socketed ones you can borrow from another PET then they may be worth a go. I presume this is only a 40col PET, so maybe it doesn't have added complication of Odd & Even interleaved Video RAM? Although I'd expect different symptoms with that, like you had on another. |
||
|
|
|
|
#34 |
|
Nonode
Join Date: May 2012
Location: Perth, Scotland
Posts: 2,446
|
You're right - it should be upper case. You'd think I should know that by now.
Photo of a normal working 4032 attached for reference. Photos of a working and the failing Tynemouth diagnostics screen attached. If we could sort out the 1 character shift it'll be easier to read. And yes - 40 column means no interleaved video RAM. Colin. |
|
|
|
|
#35 |
|
Nonode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 2,878
|
I notice that the Tynemouth Diagnostics board is able to change between Upper & Lower Case OK.
I presume that board doesn't bypass the Character Generator ROM? - as the screen RAM only stores PETSCII codes (which it seems does include both upper & lower case) . I did find info that suggested the PET should power-up with Upper-case selected by default. However, others seem to have found the opposite: https://forum.vcfed.org/index.php?threads/cbm-pet-uppercase-writing.1241986/ Where it seems it depends on whether you have the 'Home' (Graphics) Keyboard or the Business Keyboard - And presumably different ROM's or links (on Keyboard?) that sets what should be used? So working out how this is meant to work seem to be useful in trying to sort this. Does your 4032 PET have the same Keyboard as this 4016 PET? Maybe there were also different CharGen ROM's required between these? And it might be worth double-checking your newly created one is right for this model? I have seen references to a 4KB rather than 1KB one, with extra character sets? Are you able to type anything / change case from the keyboard? I am wondering if finding-out why the case of characters is incorrect may be easier than trying to work out why there seems to be an address-offset (and may well have a common cause?) I see that the Tynemouth Diagnostics screen also shows the border-frame segments also shifted back by one Byte so left-side ones appear on the end of line above. The Tynemouth Diagnostics also indicates lots of RAM errors - mainly on bits 3, 2 & 1 ? - Maybe the RAM needed by the 6502 stack etc is OK for Computer to boot, but other locations have bit-errors? If it was a buffer, I'd expect all locations to be at fault? Also, is there a location held in main RAM that could be dodgy, which controls what character set is being used? I presume the extra (memory) Hi Res Graphics board also gave you 80column mode? And I am wondering if something changed to use this hasn't been fully-reverted correctly so could be causing the odd 'faults'? Maybe now that some dead IC's have been replaced, it may function OK if refitted? / it might be worth trying to fit it to another PET to test it first? - There's rather less to go wrong on this than on the PET main board, so I thought it might be worth trying. And if it does actually seem to work OK, then could try refitting it to this PET to see what it now does. Last edited by ortek_service; 14th Apr 2025 at 12:39 am. |
|
|
|
|
#36 |
|
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 13,872
|
There may be something in that - as Owen suggests there may be something on the mainboard which was modified in order to accommodate the way the add-on graphics board needed to work which hasn't been un-modified yet.
Now that genuine faults have been found, enough to get the machine almost working and showing correct startup prompts, it might be useful to see what happens with the add-on board refitted before going further. |
|
|
|
|
#37 |
|
Nonode
Join Date: May 2012
Location: Perth, Scotland
Posts: 2,446
|
There is one patch wire that does not look like it was fitted at the factory - UC3/3 to UD4/11 and the trace on the motherboard to UC3/3 is cut.
I will try to dig out the graphics board installation instructions to see if it was part of that setup before I do anything - part of the difficulty is that the graphics board is a HR40B and so far all I can find is the installation instructions for the HR40. I'll let you know what happens if/when I remove the patch and reinstate the connection that has been cut on the motherboard. With regard to the character ROM, I burnt it onto a 2716 and have swapped it into the working 4032 and that works fine. Colin. |
|
|
|
|
#38 | |
|
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 13,872
|
Quote:
All of the other ROMs can lope along at standard old microprocessory speed but the one used in the character ROM position has to be pretty nippy. If in any doubt try a real Commodore ROM in-position to rule out any possibility of a problem with your EPROM substitute - but I did see you say you had tried it in another machine without problems. Yes, please do see if you can find any information about what those non-original mods were for and try reversing them to see what, if any, difference it makes. Edit: I think you may have been composing your post below when I posted this. Last edited by SiriusHardware; 14th Apr 2025 at 1:12 pm. |
|
|
|
|
|
#39 |
|
Nonode
Join Date: May 2012
Location: Perth, Scotland
Posts: 2,446
|
Progress of a kind.
I removed the non-standard patch cable with no effect. I then had a quick look at VCFED with a similar problem: https://forum.vcfed.org/index.php?threads/cannot-use-eprom-to-replace-character-rom-in-4032.1241378/ which prompted me to use a standard Character ROM from my 4032 and the shifted left nature of the screen has now gone. However, the boot screen is still lower case and the Tynemouth diagnostic board is now giving me strange characters.... Colin. |
|
|
|
|
#40 | |
|
Nonode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 2,878
|
Quote:
And it seems there were / are some incompatibilities between the Commodore PET CharGen / OS (/BASIC/ EDIT?) ROM's and the particular main board being used. And you have to be careful to use the exact matching-versions. So I presume the 'Standard' version CharGen ROM from your 4032 has different contents / is a different version to the 2716 EPROM you'd previously programmed (Is that a 'Graphics' / 'Business' version?). Just to clarify to us, what variants are your 4032 and also your 4016? Are they both the same / and are they the 'Business' (Upper + Lower case?) or the 'Graphics' (Upper case + Graphics?) version? - I presume the keyboard markings should give it away what they should be? (Hopefully I've got this right as I'm still learning myself about all these PET differences!) Maybe, for the High Res Graphics board to work, the PET Mainboard has to be configured / have the right ROM's? (Maybe 'Graphics' ?). Although if this board has its own replacement ROM's (for 'EDIT' + CharGen?) then maybe it doesn't need certain ones fitted (as long as BASIC & KERNAL don't affect whether it is a Business(Text-Only, Upper&Lower case) or Graphics (+ Upper case only? text) variant?) I do seem to recall that Commodore put the computer-variant differences in the EDIT ROM, in order to retain the same BASIC & KERNAL ROM's - within the same 2000 or 3000/4000 (& also 8000?) series at least? Regarding the now much-more garbled screen with the Tynemouth Diag board, do you have to set any of its DIP switches in order to match the variant of CharGen ROM fitted? (I'm still assuming this needs to be fitted? as Video-RAM is for storing (PETSCII) characters only) - In order to tell it what version of PET you are using? If both your 4000 series PET's are the same variant, then swapping all sockets ROM's between them, should hopefully check for compatibilities. And if the Super High Res Graphics board can be tested on the working 4032, without having to do too many mods, then that may be useful to see if that does still work OK. It does seem like there are still some Main Memory RAM errors on this 4016, that could be resulting in some issues. Or there are problems elsewhere that are resulting in the corrupted screen in BASIC, even with the shift resolved by changing the CharGen ROM (to a different variant?) - But maybe it's whatever (EDIT / KERNAL or BASIC?) ROM expects a particular version of CharGen ROM, that is the wrong variant? - Particular ones previously removed for the Super HRG board upgrade, that you've had to replace? (I'm still unclear as to whether these can identify what variant of Keyboard is fitted, by some links on that etc?) I wonder if there's a compatibility table / matrix on the 'net somewhere, that summarises what version / variant of each hardware main board works with what ROM's / Keyboards etc.? (If not, then it would be useful to create one, with known OK / Not OK found so far, when trying to get PET's going that may have been mod-ed). I also recall recently reading that CRTC PET's had a double-capacity (4KB rather than 2KB?) CharGen ROM, so that multiple modes (more than just two?) could be support. Although if this is just translating 8bit data from Video RAM, then I'd have thought it only needs 256-Bytes per mode so even a 2716 would give 4 of these - Unless more than 8bits output is required for each Character, to completely form its colums and rows of pixels to the display? Last edited by ortek_service; 14th Apr 2025 at 3:41 pm. |
|
|
|