Jump to content

epsilon537

Members
  • Posts

    25
  • Joined

  • Last visited

  • Days Won

    4

epsilon537 last won the day on June 1

epsilon537 had the most liked content!

About epsilon537

  • Birthday 10/07/1972

Recent Profile Visitors

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

epsilon537's Achievements

Explorer

Explorer (4/14)

One Month Later Collaborator Rare Week One Done Dedicated First Post

Recent Badges

30

Reputation

  1. Two BoxLambda devlog posts for the price of none: Testing with Verilator Warnings and Verilator Lint
  2. I've been working on a build system for BoxLambda: https://epsilon537.github.io/boxlambda/make-and-bender/
  3. Very cool! It looks like X16 discord is the place to be nowadays. I thought it was pretty quiet here on the forum, but when I log in to discord I'm happy to see that lots of cool things are brewing!
  4. Another post in the BoxLambda Blog. I'm building a tiny bootstrap version of the system and bring it up on my Arty A7-35T: https://epsilon537.github.io/boxlambda/hello-world/
  5. A new post in the BoxLambda project Blog, about the git workflow I'll be using, and my setup: https://epsilon537.github.io/boxlambda/git-workflow-and-setup/
  6. I haven't worked out the cycle counts. A small part of the DPRAM, or even Praxos internal memory might be set up as audio buffer if needed. The VERA already has an audio buffer, however. YM2149 register access should be at a low enough rate, buffering might not be needed. The audio is usually not competing with graphics for bandwidth. All graphics resources reside in VRAM, not DDR or DPRAM. Although I can imagine in some cases we might be loading new graphics resources from DDR into VRAM on-the-fly, i.e. a kind of VRAM banking mechanism. If there is concurrent access from the CPU and DMA to DDR, they will be serviced in a round-robin schedule, so each can account on 50% of the bandwidth. Q1: in HW, no. No MPU or MMU. The programmer will have to be careful. I don't intend to implement any mechanisms to prevent people from shooting themselves in the foot. Q2: on the Nexys A7-100T, easily. On the Arty A7-35T, probably not, although maybe the dual YM2149s can be traded for a single YM2151. I would have to synthesize the YM2151 to see how the numbers work out.
  7. I don't think so. Either way, I don't necessarily have to track the latest and greatest in the original VERA repo. I have my own fork. I expect I'll be make changes in my fork such as giving the CPU and DMA memory mapped access to VRAM. Also, the whole point of BoxLambda is to create a sandbox for RTL and SW experimentation. That includes VERA.
  8. You can redirect the CHROUT forwarding vector at $0326 to a CLC and RTS, so a call to CHROUT will return immediately with a carry clear (success indication). Fast and no impact on VERA. MON ... .A1000 18 CLC .A1001 60 RTS M0326 .:0326 00 10 ... The emulator -echo option will still trap the call to $ffd2 and log the character to the host terminal.
  9. Collision detection looks like a challenge in a game like this. Will the algorithm also handle sprite-to-tile collisions?
  10. A new post in the BoxLambda project Blog, about interrupts and FPGA resource utilization: https://epsilon537.github.io/boxlambda/interrupts-and-fpga-utilization/
  11. Yes, it should be possible.The exact solution will depend a lot on the console chosen, so if you're going to pursue this, I think you should pick one, say NES, and focus on that. The NES is designed as a console, not a general purpose home computer, so you're going to have to add the missing pieces to turn it into a general purpose home computer. It's going to need at least a keyboard, a filesystem, and some working memory. The more you add, the less NES it becomes, however, so you're going to have to strike a balance. I think an FPGA that presents itself to the NES as a cartridge should do the trick. The FPGA has internal memory, can implement a PS/2 interface for a keyboard, an interface for a microSD card, and a serial port for file transfer to/from the device (so you don't always have to swap SD cards in and out). It sounds like a perfect retro computing project! A nice mix of hardware, software and reverse engineering. .
  12. Yes, that was how most people worked on a C64. The same computer was both the host and the target. The result was not less advanced than commercial software. On the contrary. I was in the C64 demoscene in the late 80's early 90's, and the demos the scene was outputting at that time was consistently more advanced than 95% of the games out there. The whole point of demos was to push the limit of the machine. Most games on the other hand were on some kind of budget (money and time) and were being developed with many different home computer targets in mind, so they weren't explicitly pushing the limits of the C64. SlithyMatt's comment about cross development being the norm may have been true for the bigger studios, but there was a lot of indie development going on, e.g. sceners making games and tools, and that was almost always done on a single C64, the machine being both the development host and the target.
  13. I pushed a new post, discussing BoxLambda's architecture, including an actual Block Diagram! https://epsilon537.github.io/boxlambda/architecture-first-draft/
  14. Another option is to combine an interpreter with inline assembly. An interpreter is much easier to bring up on a constrained device than a compiler. Here's uLisp for instance: http://www.ulisp.com/ On virtually all 8-bit home computer systems, that interpreter was BASIC obviously. I assume it was always and only BASIC because of the easy learning curve. But there do exist other options besides BASIC.
  15. Good point. The stable development platform is probably one of the reasons people still develop for the C64 today, but not for the Pentium PC. In a way, RTL is just software that runs on an FPGA instead of a CPU. In that sense, BoxLambda is a framework and the Arty or Nexys A7 (I haven't decided) is the stable development platform. Then again, if there exists a stable development platform for homebrew FPGA projects with good traction today, it's the MisterFPGA, not the Arty or the Nexys.
×
×
  • Create New...

Important Information

Please review our Terms of Use