Posts by AndyG

    Wonder if we can get it to work with the CBM 4022 printer ….ummm the c64 image is rotated by 90 degrees on the HSG….


    What’s the best software for creating HPGL images ?


    Andy

    It would be great at some point to get dumps of the SuperPET roms…. I had to make up a 50hz E rom and curious how the settings compare with the official ones assuming MMF9000 is setup for 50hz.. you know if it isn’t as in Superpet mode the screen will be bouncing up and down

    I am not sure if this is still up to date or if I have understood it correctly...You are looking for the 50Hz Waterloo Editor ROM ? The ROMs are available at Zimmers.net http://www.zimmers.net/anonftp…s/pet/SuperPET/index.html

    But if you still need ROM dumps, I have my MMF open at the moment, probably a few RAMs are broken. My E000 ROM is labeled "50Hz".

    My original question to ask for a dump of the E rom (hopefully from commodore) from an european superpet/MMF9000…. For comparison. I do know about the stuff on Zimmers…

    and added code for resetting OLED screens properly


    I'm afraid this breaks the correct initialisation of "normal" LCDs.


    Mine did not show anything usable with your bin...

    No it doesn't - the code is ignored if a LCD. I am running both. I have 2 OLED and 3 LCD all on the same build.


    The fact that yours would not update via a SD card is the root cause. The way round that I have found to rectify in this case is to reprogram the ATmega with the boot loader and then upload the nodiskemu on the SD card. That sets the ID. If yours is working now leave alone is my recommendation - have you tested the save bug ?

    AndyG : Can you give us some more informations about your bugfix? What was die issue? What did you change?

    That's the problem - I used a different compiler on my Mac and added code for resetting OLED screens properly (and also changes for Steves SD board to remove the need for the additional resistors to simulate the presence of buttons) . That's all. Different compilers produce different output code - I did connect with Nils for words of wisdom but as understandably he has retired from the project after so many great years with it. Basically if it works for me good ....


    I still get issues with some ATmega's as described (which the debug version resolves) but for the ones that work correctly on startup the save issue hasn't been a problem unless the SD card is corrupted.


    Why I do not understand (unless its a timing issue of some sort in the base code) which is why I am being cautious here - it should not break anything if programmed on a different petSD+ but at your curiosity risk.

    When I talked with David initially about using the MiniPro he said he did not have much success from what I recall - never got it to work reliably. He pointed me to the usbASP programmer.

    Diese liefen Anfangs einwandfrei, jetzt stelle ich jedoch fest, dass es immer wieder zu Startproblemen kommt. Wohlgemerkt: Unabhängig vom Rechner.


    Auch nicht sehr vertrauenserweckend... :ponder:


    Ich baue gerade noch 2 weitere Platinen auf (für dein großes Gehäuse :sunny:) und habe weitere (andere?) ATmegas im Zulauf. Ich werde das beobachten. Allerdings ist das halt auch nichts was man immer und ständig nutzt. Von daher ist deine Taktik des "defensiven Speicherns" (und Prüfens!) wohl wirklich anzuraten.

    There were two problems … one the startup and another is the save bug. With some ATmega chips files would not be saved properly.. they would have 0 bytes.


    So you have to save a program to the petsd+ and see if it can be reloaded. I am curious if the build I made recently overcomes the save bug as this one has disappeared now on my units … built up 5 .. if it unique to me then that's fine with me also.


    David’s website details the programming of the ATmega from initial programming using the .hex bootloader to the petsd+ nodiskemu code .. I used the usbasp to program the bootloader.


    The petsd+ will not update from the sd card if its ID doesn’t match the ID in the .bin file. I think if you have always programmed the .bin file from the minipro I am not sure if the ID is correctly set.. just my thought

    I just tried the .bin file I sent you on my spare petsd+ and it updated fine from the SD card. I have never programmed the ATmega from the Minipro TL866.


    I use a USBasp programmer with a AVR atmega32 system board to set the fuses and program the initial .hex code. After that I add the .bin fie to the SD card and program it that way. I have also programmed it via AVRDUDE after compilation but it works either way.


    The only thing I can think of is that the petSD+ will only re-program itself from a .bin file on the SD card if the ID's match. I wonder if your intial programming didn't not work fully and it needed a few goes.


    Either way if it is working leave alone.


    The version would have been yesterday's date - it's based on the last version Nils posted with a few modifications for the OLED and Steves cbmSD Mini. I agree we may never get to the bottom of why are seeing startup issues but we should never give up :)

    Hm? No OLED here. But I'll try an ATmega from other source.

    I can do a build with debug enabled to see if that resolves the startup issue for you ? I found 1/3 of the ATmega’s I got had issues which this resolved. I also refined the build for Steve’s cbmSDmini version (which was the original intend to be able to compile my own code) to remove the need for the resistors to simulate buttons were present. An alternative ATmega can solve the problem also…. I still think it’s a timing thing that includes the rtc.

    I am not by my computer ... the version I built is for OLED screens and a good working ATmega and fixes the reset issue for the OLED screen.


    I did have ATmega chips that showed the startup issue and could only get them working fine if compiled the code with debug switched on (unless you go to the 2017 version) . The main downside to that is the busy light is always on.


    I have tried messing with the code but cannot fathom out the startup issue as of now. Think it is a timing issue of some sort


    Can happily send you a build try..for the OLED screen.


    Andy

    Interesting thread here at VCFED ..one member is recreating a universal MB


    Commodore PET Universal 8032086 measurements
    I'm busy with a project to, as close as possible, recreate the PCB layout from scratch for the Commodore PET Universal 8032086. About 95% completed and have…
    forum.vcfed.org


    I agree with Vossi - I haven’t come across a PET board that I haven’t been able to fix with time and a lot of patience…

    I have found the 8050 to be sensitive to speed when formatting … you can check that with the diagnostics program. Also the top pressure pad can be worn and that causes issues also. That I found can easily be replaced by cutting out circular discs from clarinet pads.


    Of course the blink codes indicate IC issues but make sure you use the right codes to diagnose the issues… the ones in the manual are for the 4040 even though they indicate 8050 also.

    The obligatory hat plot for completeness 😊… I also relocated the supersoft code within the edit rom to avoid the clash with the combo board addressing issue above $EF000. I Used Steve G’s edit rom assembly code as the base for the edit rom and merged in the supersoft code in padded out areas and other locations. (I found loading the relocated code into ram a bit of a pain as some of the hi res animation images I saved would overwrite it.)



    Started a new thread on the supersoft boards. Below are more photos of the HR-80 re-engineered board on the SuperPET. The superpet (single combo board variant) changes the code in locations $EF00-$EFFF which messes up the supersoft code in rom ($E900-$EFFF). For some reason it’s not decoded properly or for some other reason changed. I therefore re-assembled the code to work in ram at $7900-$7FFF and it works fine. I also had to change the edit rom to a 2764 eprom and insert it into a retroinnovations 2532 to 27xx adapter board so it responds to /norom properly when switching to 6809 mode.