Jump to content

Lorin Millsap

  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Lorin Millsap

  1. On 10/14/2021 at 1:33 PM, TomXP411 said:

    If I recall, the system clock is also driven by VERA. In that case, there would be firmware changes needed for VERA to live on an 8080 style system. Either VERA would need to generate the clock, or you'd have to drive the I/O side independently from the GPU side of the core. In either event, you might as well modify the bus sequencing to account for 8080 style I/O while you're at it. 



    This is incorrect. The VERA is designed so that it’s buss interface is independent of the host clock because we want it to work on other systems. It does not generate the system clock. 

    • Thanks 1
  2. This would probably partially work on the X16 with the tricky area being the banked RAM and the zero page mapped Banking registers.  If it can be set to externally access $0000 and $0001 as external IO in addition to the main IO range, plus the entire banked range then it would work, but that’s three exception areas. 

  3. Well a lot of this is why David put out polls. See if people are expecting a fully assembled unit we don’t have the manpower or logistics. If we assemble them stateside we don’t have the manpower and if we have to assemble them in China there are logistics problems. But if it’s a DIY kit then that really helps. But not everyone is capable. I’m good at soldering and these take a while and it may be beyond a newbie. 


    it seems the majority is fine with units minus cases and requiring users to assemble themselves. For full assembled units expect to pay a premium and have a long wait time. 

    As for the X8 I’m warming up to the idea. 

    • Like 3
  4. As one of the official team member I will say first. David has not thrown his hands up at all and if that’s how your are interpreted it, that means only that you concluded that first and are only hearing what you already believe and not what he said. Secondly David is really not that directly involved in the technical aspects of the project. Micheal who is handling the KERNAL development has been very busy. For example the PS/2 code issue. I’m not a code guy, but I was aware of the issue and a solution was proposed. But due to tight schedules, hardware changes, etc. the fixed code was never merged so the current KERNAL is using the incorrect code. The reason it doesn’t work with the faster CPU is because the timeout runs faster too and it reaches the timeout before the keyboard gets ready. The code needs to be updated to prevent that. 

    As to other issues, we are dealing with supply chain issues which are not unique to us. You have cargo containers sitting on ships for weeks, you have factories halting production on all but a few lines, the global chip shortages, etc. 


    And another point, for a project that as of now isn’t a crowdfunded project, how many are this transparent.  We have ongoing tests with the existing boards are a trying to get enough parts to complete a few more boards. Fingers crossed if it goes well there will be only one more board revision and the project will advance to the preorder stage. 

    • Like 5
    • Thanks 5
  5. A while back, my brother told me that he would like to create a program for the Commander X16 that would be able to convert a program/game written for the Commodore 64 to make it run on the Commander X16.
    Preferably, it would do the conversion on the fly, but a conversion from file to file was not out of the question.
    I told him that it would be close to impossible to create such a program as it would mean that he would need 100% understanding of the inner workings of the C64 and be able to figure every demo-scene programmers tricks out in his own program.
    Our conversation ended there, but I have been thinking about this ever since and now I have written a short guide (mostly to convince my self that it can not be done) on how one could go ahead and do it.
    Have a look at https://techblog.dansbo.dk/?p=366
    What do you guys think, would it be possible to create a program that can convert almost any C64 program to Commander X16?

    No. The hardware is too different. The only stuff that will convert over with little or no change is text based stuff. It is possible to pseudo mimic the SID.

    Sent from my iPhone using Tapatalk
    • Thanks 1
  6. I also looked briefly at the code that handles SD card communication (dos/fat32/sdcard.s).
    It's a bit banged SPI solution that depends on proper timing.
    The necessary timing delays are measured in processor cycles, calculated on the assumption that the X16 runs at 8 MHz.
    It would be surprising if the code worked properly if you run the computer at 4 or 2 MHz.
    Before any other troubleshooting, it would be interesting to know how well the SD card communication works at 8 MHz. To test this you may first need the keyboard to work at that speed [emoji846]

    SPI has no strict timing requirements. It should work regardless of system speed.

    Sent from my iPhone using Tapatalk
    • Like 1
  7. I think they are going to have a lot of difficulty pulling off 8MHz, even exploiting early address bus stabilization, if the parts shown in the videos are correct (xx74ACTxx logic, Alliance AS6C4008 SRAM). With tACC=70ns on the CPU and tACE=55ns on the SRAM, there may only be 15ns available from address stable until the correct CS# must be asserted. Those gates have a propagation delay up to 9.5ns, therefore if your output requires more than 1 level of combinatorial logic (which I think is guaranteed to be the case for memory below $9F00), you have the potential to hit a timing violation. Switching to faster xx74AHCTxx components will let you have two levels of logic if your load capacitance and temperature are sufficiently low (i.e. 15 pF and 25C or better). If I recall correctly, the problem with the v2 prototype board was that CS and PHI2 were effectively being ANDed together which should never work at 8MHz because you have less than 55ns from PHI2 until the end of tACC.

    A16-A23 should not need to go through a PLD unless it is also demuxing the data bus, which is quite a bit more expensive than using a 74AHCT245 and only 1ns faster. In my experimental case, I only feed the high address bits into the SPLD and only the chip select signals come out.

    Incidentally, the SPLD has a propagation delay as low as 7ns so you could go through two of them without a timing violation at 8Mhz on a 65C02. I'm not expert working with these old parts, but going strictly by the numbers, I just don't see how CX16 is going to be able to run stable at 8MHz unless the published timing values are all lies. If they do manage it, I am probably going to buy a sacrificial unit just to connect to the logic analyzer and figure out HOW. At 4MHz, all of this concern goes away and delay for demuxing the data bus is not going to be fatal to a 65C816.

    HCT is not faster. ACT is way faster. However as a while you are right.



    Sent from my iPhone using Tapatalk

  8. Thanks [mention=28]Lorin Millsap[/mention]!
    I looked at and calculated the wait loop on lines 55-60 in the file x16-rom/kernal/drivers/x16/ps2.s (Github master branch) once more.
    • The loop setup on lines 55-56 is 4 cycles. The loop counter (Y) is set to 80.
    • Each loop (lines 57-60) takes 11 cycles. The test for a start condition happens 4 cycles into the loop.
    • The loop will check for a start condition 79 times
    • The last check will happen 4 + 78*11 + 4 = 866 cycles after the I2C lines were released
    • 866 cycles @ 8 MHz processor speed is about 108 us. @ 2 MHz it's about 433 us. If the keyboard hasn't started to transfer data within that time, the PS/2 lines are made inactive again.
    • As far as I can see, there are no other parts of the Kernal PS/2 code that has a similar timeout. If receiving a start condition, the code will wait (indefinitely) for the keyboard to finish transmission.
    • Instead of lowering the processor speed, you could increase the value of the loop counter on line 56. If the counter is set to it's maximum value of 255, the timeout will happen after 349 us.
    • If that's not enough, you could add one ore more NOPs to the loop for testing purposes. One NOP at the beginning of the loop would increase the wait to about 414 us if the loop counter is set to 255.

    In my view the timeout should be removed and a separate system based timer should be used. The same VIA chip has timers and they can be configured to count higher. Also running in a loop defeats the purpose of switching the circuit to IRQ based.

    The way the PS/2 has now been setup it is connected to VIA0. This VIA has its _IRQ line connected to the CPU _NMI line which means IRQs generated by this VIA cannot be ignored. The theory is that you only use IRQ functions of this VIA for PS/2 related functions. For most software unless you are doing timing critical stuff there is no problem with the PS/2 keyboard generating these NMI events at pretty much any time. It will just read the data as it comes in, and you just disable the keyboard at times when you don’t want interruptions. Normal behavior will be to inhibit mouse except for once per frame if the mouse is enabled. And the mouse and keyboard will have to take turns.

    Sent from my iPhone using Tapatalk
    • Like 1
  9. I remember [mention=28]Lorin Millsap[/mention] said some months ago, that the current Kernal function for reading the keyboard would not be the one to be used in the final product.
    On Github, there is the "ps2-nmi" branch last updated at the end of April. I haven't analyzed the code, but it seems to be an interrupt based solution instead of the polling method used in the current master branch.

    I’m certainly not an expert on the code. But what seems to be happening is the PS/2 code that was used was written in a poll type interface. PS/2 was meant to be interrupt driven. Because the code is Polk based it inhibits keyboard communication except when it wants to. On a CPU cycle limited system like a VIC20 or C64 where you need to read things within a narrow window of time that works fine. And on our system this is still somewhat the case, except it needs to to be implemented differently. Holding the click line to inhibit communication is not the problem. The problem is the code essentially hits a timeout, and if the keyboard hasn’t started transmitting by the time the code times out, then it misses the data. When it’s run at lower speeds this works fine, but when the CPU speed gets increased then it times out faster. I thought Frank wrote some new code that worked better, but apparently it never got merged in.

    Sent from my iPhone using Tapatalk
  10. Reality has simple text printing shouldn’t be that hard, but yes you need some type of microcontroller based bridge adapter to translate between say an Epson protocol to a modern printer. Probably pretty steep got Arduino, but a Pi could absolutely do it provided you are running some widely supported Linux host do that it can use standard print drivers. The it could take the source machines text or simple graphics output, convert it to some type of image, probably PDF or ODF and then print that image to a modern USB or network printer.

    Sent from my iPhone using Tapatalk

  11. I'm sure there are lots of behind-the-scenes reasons why this hasn't happened, but would it be possible to get someone to push the "R39 = official" button on the Github repo? My R39 workarounds include doing some manual things because cc65 gets broken on R39, and there are other tool chain projects like Prog8 etc which are also in limbo until this major revision gets officially blessed. I'm intentionally keeping my tools frozen as long as R38 is the official version, and I've read posts here and elsewhere by those who are ready to merge updates into cc65, etc.

    The reason it hasn’t been pushed is there are some hardware things having to do with keyboard and mouse handling which haven’t been tested on real hardware yet. However the R39 is there and can be compiled, and so long as you are using Kernal routines it should work. Personally I think R39 should be pushed and if it turns out we need to make some hardware changes we can push out an R40 release.

    Sent from my iPhone using Tapatalk
    • Like 7
  12. There is no reason to support R38 as R38 doesn’t reflect the real hardware. You should shift your code to R39 or have separate binaries as R39 doesn’t have an official release yet.

    Sent from my iPhone using Tapatalk

    • Like 1
  13. Levels:
    Simple level: You tell the task switcher the range you use in the Zero page, and the range you use in Low RAM, it writes a file to the SD card that stores the current values of those when called. It does nothing to HighRAM ... if you have HighRAM data to store, that's up to you. It also tells the task switcher it's name. The task switcher resides entirely within a single HighRAM segment except for the small stub in Golden RAM which is used to call it.
    The only difference here to having "something" in ROM is that the task switcher HighRAM bank is a System allocated bank and there is no need for the stub in GoldenRAM.
    Middle level: this is the one I blathered on about above.
    Higher level: for cooperating programs, there is an allocator of HighRAM, on a simple "stack & heap" model, executables and mixed data and executables allocated from the bottom up a segment at a time, data segments allocated in groups as needed from the top down. A two bit BAM for "System / Stack Allocated / Free / Heap Allocated" is 2bits x up to 256 segments for 512 bits or 64bytes. The task switcher would be able to check what the allocation was when it starts, and keep track of how much each one uses. Maybe programs that DON'T use the allocater ought to exit by rebooting, so the task manager only has "retained" data from programs "popped up", which is just the state that a pop-up popped up into, and "saved" data from data that was in a chain of tasks done in a cycle. So when you exit the pop-up, instead of freeing the last task program and data segments and grabbing the next one, it just frees and you go ahead with the data that is sitting "underneath".

    I like the lower level the best. Except I wouldn’t make an SD file. I would prefer to use a portion of highram which is KERNAL reserved for that purpose.

    The task switcher should be part of the menu integration. When a task switches, it just goes to a menu which will display any resident integrated programs, so BASIC and EDITOR, and the integrated monitor for example, and any other ROM resident programs, followed by current RAM resident programs. Then the menu will also have quick items which are things stored on the SD that you use frequently. And it would have a browse option so you can go find anything by browsing the SD contents.

    The integrated file browser needs to be part of the KERNAL load and save functions, as well as error handling. The C64 left most error handling to the programs, which was rarely actually implemented the way commodore suggested. For example if you load abs a file not found error is returned, I argue it should use an integrated error handling routine that should tell you the nature of the error and give you options about what to do. This would greatly enhance basic as well as end user programs.

    Sent from my iPhone using Tapatalk
  14. My desire to add to ROM is a "improved" BASIC-like interpreted language. One that supports multiple tasks and provides an almost GEOS like interface, but all in a text / tile based interface (think along the lines of the TEOS project; https://www.youtube.com/channel/UCrELuExo6T_USEqELq1xVHQ for videos).

    In my case, it would not be designed primarily for native code (though it would ideally support native apps if they wanted to use it not unlike BASIC / KERNAL routines). The utility of it in my mind is by making the interpreted code position independent (even more so that BASIC) it could support multiple simultaneous tasks and even crude multitasking without having to play with IRQ task switching. I think it would provide a "linear" address space to gloss over bank switching and other hardware abstraction layers to support sharing the single VERA or other hardware resources more easily.

    This could all be done without ROM, of course. With as much RAM as is available, it would not be a huge pain point to sacrifice RAM to the run time. But it would be nice if those static unchanging parts of the system that multiple applications depend on are in ROM so as to keep as much RAM free as possible.

    Things like that could be fine though again they would function just as well from RAM.


    But I do like the comments about a proper task switcher, it would provide a nice way to exit programs in general.



    Sent from my iPhone using Tapatalk

  15. Can someone explain some of the details involved in designing an expansion card that maps itself into ROM based on the position of onboard DIP switches? Like... bus arbitration: how you would make sure the card is what gets accessed and not the empty slot in the ROM on the motherboard — or worse, both.

    Expansion cards cannot map themselves into ROM. There is no exclusive arbitration there. The expansion slots do expose the entire bus so DMA techniques can be used, but ROM mapping is not a supported function. However this thread is not the right place to ask your question.

    Sent from my iPhone using Tapatalk
  16. Hi.
    I've been involved in discussions on two use cases that are quite similar: Using the text editor I've developed to write source code for
    • Volksforth, and
    • a resident file based assembler
    It is of coarse possible to
    • load the text editor from SD Card, and start it
    • load the source file from SD Card
    • edit the source file
    • save the source file to SD Card
    • load the assembler or Forth compiler from SD Card
    • assemble or compile
    • load the executable from SD Card
    • run the code for testing
    • repeat
    However, all these steps will be tiresome to do over and over again.
    The issue will be present for any setup that uses two or more programs in parallel.
    One solution is to keep at least one of the programs in ROM, if that's supported by the platform. That's very convenient, much the same way as cartridge based utilities in the old days.
    There might be other solutions, for instance dividing the RAM between programs. Unless there is a load function that may relocate code, programmers must agree in advance upon the division of RAM resources.
    For any two programs that can easily be done if the programmers just talk to each other. But the complexity grows with the number of programs that are to be synchronized to each other.
    But it is what it is. If the platform will not safely support ROM based user programs, we must use what resources are available. As evident from history, great ideas will often come to light to overcome limitations put upon us.

    Number of programs loaded is a non-issue on a system that lacks multitasking. Hypothetically you can multitask, but the OS itself does not support it. So that’s largely a non issue. And locating one of those in ROM does not solve that issue.

    You have up to 2 megs of RAM to play with, and most programs do not have to share with other programs.

    Sent from my iPhone using Tapatalk
  17. I keep repeatedly seeing the idea of people using the ROM to store custom programs such as games. This is stemming perhaps because we have made it known that the ROM will be in system flashable.


    However I just want to clarify this is not the intended function. From an official stance obviously you can do whatever you want with your system but we (the X16 team) are not encouraging this practice.


    The ROM is primarily for the core OS, which is the KERNAL, BASIC, a few common support routines, the auto loader, the GEOS dependencies, BASIC extensions, and KERNAL extensions.


    The ability to flash the ROM is intended for post deployment bug fixes, patches, and the installation of certain drivers.


    Now maybe I’m missing something here, and if so discuss it. I always find it helpful to discuss the actual use cases rather than just hypothetical open ended functionality.


    In practice we are going to have an auto booth feature in the X 16 and it will load based upon a configuration file on the SD card. From which it is possible to boot up to some kind of menu or to load a sequence of drivers or any number of things not entirely unlike how DOS system would function. The loading from the SD card is generally fast enough to make most ROM patches unnecessary. I say most because there are obviously still circumstances where a ROM patch might be needed or at least preferable.


    Off the top of my head a few such use cases could be:

    •A drive controller that is bootable. Envision something like a second SD card, a SATA controller, etc.

    •A network interface that is bootable. Envision like an ethernet or wifi adapter that enables a NetBoot type feature.

    •Second second display controller. Obviously a display especially if you want to use it instead of the integrated VERA needs to work from POST in order to provide meaningful use.

    •A usb keyboard/mouse interface. This would need ROM integration as there are keyboard inputs that can be used for setup, diagnostic, and boot select features. If you used a USB adapter card and it wasn’t recognized at POST you wouldn’t be able to use those features.


    In short part of what I’m proposing is that the ROM be reserved for the core OS and for routines and drivers that augment that especially for expansion card devices that you may want or even need to always be resident in ROM instead of loading from the SD card. This would especially be true of devices you either want or need to be bootable, or that you need to be active as part of instead of after POST.



    Sent from my iPhone using Tapatalk

    • Like 2
  18. I guess not. The software that is on the system is stored in the read-only-memory (ROM), and contains the Kernal, BASIC and perhaps other utilities. Petscii Robots is designed to be loaded into RAM and run from there. Most notably, it is larger than 16 kB (even the shareware version is more than 18 kB, so the full version will be more than that https://www.commanderx16.com/forum/index.php?/files/file/156-attack-of-the-petscii-robots-shareware/). Since ROM only occupies 16 kB of address space, it would be very hard to redesign the game to run out of ROM.

    It would be even larger than that since the X16 version will be designed to take advantage of the X16 graphics and sound capabilities which would be more resource intensive than the Commodore versions.

    Sent from my iPhone using Tapatalk
  19. Two things: it harkens back to computers like the C64, and it avoids that claustrophobic feeling where the text is bunched up against the edge of the screen. Like printed text, that always has margins.
    I am of course not advocating for a mandatory border, just for an option to have one.

    What does a nostalgic feel have to do with anything unless it has a function. If you feel like your text is too close to the edge of the screen, adjust your screen. The feature is there, it’s just your screen does it.

    Sent from my iPhone using Tapatalk
    • Like 3
  20. One thing that's not very retro about the X16 is that it fills the screen all the way to the edge, with no border. I'm not a fan of that, as letters sit only a pixel away from the left edge of the screen and often there's an enormous amount of unused space to the right.
    So it would be great to have a more C64-like border around the active part of the screen. For instance, the VERA could be set up to output an 800x600 signal with within that the 640x480 image, so 80 pixels of border on the sides and 60 pixels of border on the top and bottom.
    I'm not sure if it's feasible to run in 1920x1080 with the X16 image at 2 x, so 1280x960 with 320px borders on the sides and 60px borders top/bottom, but I think that would look really great.

    What’s great about a border?

    Sent from my iPhone using Tapatalk
  • Create New...

Important Information

Please review our Terms of Use