Jump to content

Lorin Millsap

Members
  • Posts

    193
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Lorin Millsap

  1. 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.
  2. In Bruce’s defense, he is very engaged, so he is a fairly reliable source.
  3. 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.
  4. 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
  5. Yes and no. Using 256 color mode is unlikely unless your resolution was really low or you figured out how to do it in tile mode. In reality you’d probably drop the color depth and resolution. Sent from my iPhone using Tapatalk
  6. SPI has no strict timing requirements. It should work regardless of system speed. Sent from my iPhone using Tapatalk
  7. Sorry. I missed that. However I think we are already using it in a few places. Sent from my iPhone using Tapatalk
  8. HCT is not faster. ACT is way faster. However as a while you are right. Sent from my iPhone using Tapatalk
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. What makes you think parameter passing is beyond the scope of BASIC? Sent from my iPhone using Tapatalk
  15. And the precompiled executable on the website doesn’t work because? Sent from my iPhone using Tapatalk
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. What’s great about a border? Sent from my iPhone using Tapatalk
  24. A user port certainly is a serial port. What we aren’t including is a UART or a modem which would allow faster transfers. The user port could also certainly be used as a parallel transfer instead of serial, so with the right interface you could still get respectable speeds. Sent from my iPhone using Tapatalk
  25. The ability to reflash the ROM is not intended for adding user programs. Sure you could, but it’s akin to adding custom programs to your BIOS. It’s intended for the KERNAL and useful extensions. The risk of corrupting the ROM is fairly high. The SD card or other storage device is where you locate your programs. Sent from my iPhone using Tapatalk
×
×
  • Create New...

Important Information

Please review our Terms of Use