Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 05/16/21 in all areas

  1. 2 points
    I decided to post a video update to YouTube discussing the latest things I've added to the game. It now has selectable difficulty. I am not going to push an update to the software library at this time, though, because I want to get the difficulty selection to be visible on the screen - but thanks to you guys here in the community, I decided that this would be a good feature to add, even though the original was just "you get what you get and you don't throw a fit." P.S. - I -know- my mic sucks. I'll get a better one if I decide to keep making narrated videos on YT.
  2. 2 points
    It's not just a matter of sending a byte from one channel to another. There is a file system that has a definite structure. The CPU is what processes that structure. Looking up the file allocation table, enumerating directories, opening files, seeking to offsets, reading clusters, copying the data around. That's not functionality that comes easy to an FPGA without having a programmable interface. 6502 is one of the smaller mainstream CPUs and it takes by one estimate about 700 lookup tables (https://electronics.stackexchange.com/questions/400504/how-many-luts-are-needed-to-implement-a-cpu). There is a lot of logic that goes into processing a file system. I've worked for a couple companies over the years that dealt with file system processing, and I've written a complete user mode implementation of NTFS and FAT32. In other for the FPGA to decide where to send a byte it has to have an implementation that can process all the details of the filesystem. It can be done, but it is far more complicated than just "send the byte to channel X". Edit: I wrote complete read-only implementations of those file systems to read data from a cold backup image that was just stored as a collection of clusters. I've not written a writable interface, but since we're talking about reading from the file and writing to memory, I have direct experience with that. I even have a patent on identifying what files changed in an incremental image based backup. I don't mean that to brag, just to establish credentials.
  3. 2 points
    Not truly a meme, but jokes about some retro arcade games in this USSR cartoon at timecode from 2:52 to 3:26. Shown here are USSR arcade games Highway, Sea Battle, Safari and some shooting game unknown to me. But I know that most USSR arcades were clones of western ones, so I'm sure you will see familiar games.
  4. 1 point
    I am mostly using 2.7.2.255 that can be found here: https://sourceforge.net/projects/circuit/files/2.7.x/2.7.x Development/ So far I have had no issues with it.
  5. 1 point
    You need to read the VERA ISR register. I have a video about the basics of interrupts here: Then I have a video on how to manage LINE and VSYNC interrupts here:
  6. 1 point
    I have been using Logisim for a couple of years now. I have also tried Digital and other's, but still like Logisim best. Would love to see a modern (read no-java-based) port of Logisim that has the same functionality.
  7. 1 point
    A number of system functions (keyboard, mouse, and controller scanning, updating the jiffy clock, and blinking the cursor) are performed by the kernal IRQ handler every time the VSYNC interrupt occurs. I believe the best way to restore these functions would be to enable both VSYNC and LINE interrupts, and to check which interrupt occurred in your code. If it was a VSYNC interrupt, jump to the original IRQ handler. If not, execute the line interrupt code. Currently, most of the things that the X16 inherited from the C64 (BASIC commands, kernal routines, vectors) are completely undocumented.
  8. 1 point
    You need to enable the VSYNC IRQ, too. Enabling only the LINE IRQ messes up the kernal, which is expecting that VSYNC 60 times a second to keep it regular. It should only be disabled for short periods where you need to maximize CPU usage on some task, and don't care about I/O until it's done.
  9. 1 point
    Yes, it is physically possible to build the functionality you would prefer directly into the FPGA. It would mean either getting a larger FPGA, which would cost more money, or it would mean decreasing the amount of video RAM or other functionality (such as audio). There ain't no such thing as a free lunch. Something has to pay for the increased functionality which does not happen magically. The goal of the platform is to provide an 8-bit system in the style of what was used 40 years ago today (and suddenly I feel old). Modern support chips are in the opinion of some a step too far, but given the lack of available modern production of equivalent chips for video, audio, and so on, it is a necessary compromise without which there would be no real possibility of a Commander X16. Forcing the 65C02 to be involved in processing means that the process is less efficient than it could ideally be. That is the compromise that was selected for this design. Every design has compromises. Regardless of what we might like to see, it (almost definitely) isn't going to change at this point. I qualify it thusly because I don't make any decisions and acknowledge that it is a statement of opinion, but it is an informed statement of opinion.
  10. 1 point
    What's more, doing a ROM update should probably be done on a UPS to avoid the scenario of a half updated ROM (particularly in the case of trying to update system ROM banks) in the event of a power interruption.
  11. 1 point
    In order to change to 40x30 mode, you should use the screen_set_mode kernal routine. In addition to changing the screen size, this routine sets some variables in the kernal that are used to determine when to scroll the screen.
  12. 1 point
    This one is really creative.
  13. 1 point
    I'll probably be doing an update on the X16 in a month or two. It might be good to show this assembly environment off again. Has anyone written anything in the environment that would make for a good demonstration?
×
×
  • Create New...

Important Information

Please review our Terms of Use