• Sprites and 3D

    adam.klotblixt10/18/2020 at 08:26 0 comments

    Last week I implemented ports to access sprites from the 6502. Quite interesting how much HW-sprites offloads work from old CPUs, it really pays off! Not quite done yet, but good enough to test from basic.

    Yesterday I got an Ender-3 V2 3D-printer, so now I can finally build a proper case for the PZ1. It is really different to work with 3D-CAD compared to coding, but I like both. Nice to be able to swap between different tasks and ways of working, and the result seems to come out very good. Pictures later, when I've passed the alpha levels of case design. As with code, (almost) nothing is correct on the first try.

  • A sea of pixels and power

    adam.klotblixt10/07/2020 at 14:25 0 comments

    More HW has arrived!

    The long awaited Gameduino 3X screen has crept slowly to me from USA, and finally landed at my doorstep. It is a marvellous screen with its own GPU, and a totally different way of programming. More similar to modern 3D-accelerators, but limited to 2D.

    4.3", 480x272 pixels, 24-bit colour, 1024KiB screen ram, built in fonts and 8MiB flash. WOW! The tricky part is that it really doesn't have a simple frame buffer, but instead uses commands in a display list. Takes some time to get used to.

    After some frustrating manual reading and testing I've finally gotten what I want for a start: an 8x8 text-mode with back- and foreground colours and way too many sprites :) All synced at a buttery smooth 50Hz.

    The screen with the Teensy 4.1 and its 8MiB PSRAM makes this emulated 6502-system extremely capable.

  • A sea of memory!

    adam.klotblixt10/01/2020 at 14:55 0 comments

    I got a Teensy 4.1 and soldered an extra 8MiB PSRAM to the underside. The PZ1 6502 now sees 4MiB of memory, which is the maximum possible due to 16KiB banks. Interestingly, I can measure NO slowdown in the emulation even though the PSRAM is a serial memory. I am very pleased!

    To test the memory a bit I made some thread-code that changes the colour of one pixel every frame, then yields the rest of its slot-time. The X-position of the pixel is the thread-number, so when I start several threads, I get an informative colour cycling pattern on screen. There is a limit of 63 threads, which feels like more than enough for a 6502-system.

  • Keyboard

    adam.klotblixt09/19/2020 at 03:41 0 comments

    I've rebuilt keyboards before. Liking/wanting thin and split keyboards necessitates doing that, there are none ready to buy. Lately I've wondered about minimizing the number of keys as well. Suddenly I got the urge to try it out, and that lead to a new experimental PZ1-keyboard!

    It communicates via standard serial, not USB or PS/2 connection. This makes it a LOT less bothersome to receive data from :)

    Now I only have to figure out a good way to make some keycaps or overlay. It is definitely much smaller than the real keyboard I've used so far. We'll just see which I prefer down the line.

  • Banks of memory

    adam.klotblixt08/31/2020 at 15:00 0 comments

    Since I've worked on the HW aspects of the project I started to question my choice to divide the 64KiB memory space into 8 banks of 8KiB each. I guess 8x8 had a nice ring to it...
    The HW is now designed with 4x 16KiB banks, and the SW has changed accordingly. It lead to significantly fewer number of cycles required in thread switching, and the code actually looks much cleaner since the banks are fewer. It also feels like 4 is a very good number to use, 1 for the scheduler/OS, 1 for the main code/stack/ZP for each thread, and 2 more to make swapping/copying in each thread painless. Fewer banks would be cumbersome, more banks are not really necessary very often.
    One downside is the increased waste when doing small threads, but that is not a real problem with all the memory available in this system.

  • More HW

    adam.klotblixt08/27/2020 at 12:29 0 comments

    Well, I seem to have the HW bug.

    I could not let go of figuring out how to do the PZ1 in real HW, and have been working at solving the bank switching. I started sketching it with 74-chips (done), and now I am using the rather arcane program WinCUPL to design a solution with an Atmel atf750c-chip that solves the bank switching. It's not really powerful enough to be a CPLD, but a bit better than PAL/GAL.

    WinCUPL is really bad at giving hints about what is wrong, so too much time has been spent on trying to get a syntactically correct description. I now have a description and simulation vectors that seem to do what I want. I am really tempted to order parts now, but I'll mull on it for a while first.

    The only reason I chose the atf750c was because I've got a Dataman S4 programmer that supports the chip :)

  • HW thoughts

    adam.klotblixt08/20/2020 at 07:16 0 comments

    I've claimed that this computer is possible to build, it is not only a SW dream. Well, to see if my claims still hold true I've had a go at making a schematic for the memory and bank-switching logic. Using available 74HC-logic and a 512KiB SRAM, I've used 18 chips to make it equivalent to the SW-implementation. While doing this I realise that it id indeed possible to do in HW, but anything faster than 2MHz would probably not work because of all the propagation delays. It would also take up quite some space, even if using surface mounted chips.

    If I really want to do this in real HW, an FPGA or CPLD would be a much better choice. Or a ROM of some sort, together with the registers.

  • It's alive!

    adam.klotblixt08/13/2020 at 10:44 0 comments

    Latest improvement: battery and power/charge circuitry so that PZ1 for the first time is a truly stand-alone laptop! It was a while since I measured the power requirements, but based on those old numbers (~1.5W) the battery should last at least 12h.
    I also took the opportunity to zip-tie everything.

  • 6502 verified!

    adam.klotblixt08/09/2020 at 12:54 1 comment

    For the 6502-emulation I've used source from fake6502 and miker00lz Arduino 6502 which seems to be based on fake6502 as well. They both had some small issues that I've improved as I've used the code, but one aspect I never fixed was ADC/SBC decimal mode. Today I started verifying the emulation with a test suite found at https://github.com/Klaus2m5/6502_65C02_functional_tests/tree/master

    Klaus has worked very hard on testing the functionality of the op-codes, and has had some very interesting discussions with several persons on the 6502.org-forum

    I have now run the full test suite and fixed the ADC/SBC errors, so now I can say with much better certainty that the 6502-emulation works.

    The inner workings of ADC/SBC is not very easy to grasp, I had to search for a while before I found an implementation that was already verified and modify my code from there. Thanks to Marek Carcz VM6502: https://github.com/makarcz/vm6502 for a correct and verified ADC/SBC!

  • Twice the power!

    adam.klotblixt07/28/2020 at 11:22 0 comments

    I have refactored a lot of the code, including cleaning up and moving the basic to lower memory. ehBasic may be free and powerful, but it is also quite a mess in places.

    I can now load 2 instances of basic, each using a separate serial port. Both are running in fully separated 64KiB memory windows, except for the HW ports. The main reason to run 2 basics is to test thread communication, which I'll start on next.