Jump to content

Lorin Millsap

  • Content Count

  • Joined

  • Last visited

  • Days Won


Lorin Millsap last won the day on July 21

Lorin Millsap had the most liked content!

Community Reputation

210 Excellent


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. What makes you think parameter passing is beyond the scope of BASIC? Sent from my iPhone using Tapatalk
  4. And the precompiled executable on the website doesn’t work because? Sent from my iPhone using Tapatalk
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. What’s great about a border? Sent from my iPhone using Tapatalk
  13. 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
  14. 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
  15. You read or write it like RAM but certain requirements have to be met to do so since accidentally writing to ROM would be disastrous. We will document the process once it has been tested since so far we have only ever flashed to ROMs externally. In summary though, you need to have a jumper on the board set, then you need to write a specific sequence enable writing, and during the process timing requirement have to be met. Because of the stakes, it is not something you can casually do. Failures can corrupt the ROM and essentially brick the device. You would need a replacement ROM or a programmer to fix it. Sent from my iPhone using Tapatalk
  • Create New...

Important Information

Please review our Terms of Use