Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

Recent Profile Visitors

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

  1. I think it looks a good bit like Algol, from which C and Pascal descend, but with fewer parentheses.
  2. If I'm following right, the advantage to splitting the upper 32K out is that you don't need to power/use the rest of that decoding logic for ZP if A15=1, only if A15=0. As for Bruce's suggestion to wire OR the hex drivers' outputs, I find that a more elegant solution than my suggestion of a diode OR gate, because voltage levels are likely more stable with Bruce's approach vs. diodes.
  3. On that note, for your build, maybe a 15-input diode OR gate with an inverter on the output could indicate writes to $00 or $01 without needing lots of gates.
  4. Thanks for clearing that up.
  5. Ben Eater's address decoding scheme is simple, but IIRC it divides the 64K of address space up into 32K of RAM, 16K ROM, and 16K of I/O space. Did I miss a move of the banking control from the VIA to zero page? If so, the programmer's guide is out of date. I suppose that should be no big surprise if they're still in the midst of making changes still.
  6. I think the banking does ultimately take place using I/O. From the programmer's guide, VIA #1 is dedicated to banking control, with port A controlling RAM bank and port B controlling ROM bank. The Commodore 64's 6510 processor reserved addresses $00 and $01 to control banking, but I don't think the Commander X16 is mimicking that in it's address decoding.
  7. Your approach looks to be running all sixteen address through a set of gates. Most approaches to address decoding I've seen are using far fewer bits, often the upper 1-4 bits (A12-A15). Given the memory map I've seen for the Commander X16 shows a 256-byte I/O space, and all other areas being in the 4K-32K size range, I'd guess they're decoding the upper 8 bits of address. Fewer bits of decoding results in fewer and shorter sequences of gates. You might want to take a look at the examples at http://wilsonminesco.com/6502primer/addr_decoding.html. I think it was the inspiration for the approach Ben Eater took in his videos; if not, it is at least very similar.
  8. If you take a look over at the 6502.org forums one of the first things you learn is that ROM is too slow at even moderate CPU speeds. Accessing that ROM directly requires techniques like wait states or clock stretch to accommodate. There are techniques that get around that, such as copying the ROM to RAM then banking it out, or skipping ROM and populating RAM externally via microcontroller at boot, or using a CPLD to do something similar. Rather than an EEPROM, address decode logic may be sped up by switching to a faster family of 74-series chips, or replacing them with programmable logic like a GAL, a CPLD, or even an FPGA. A FPGA or even a large CPLD would be something of a waste if all it was used for address decode logic, but there's plenty of other things it might potentially help with, like an SPI controller, an MMU, etc. I recommend taking a look at Garth Wilson's 6502 primer (http://wilsonminesco.com/6502primer/) if you're serious about building a computer based upon a member of the 65XX family of CPU's.
  9. Looking at reviews and photos on the Ultimate 64, it looks to me like the U64 eschews physical instances of the typical supporting 65XX chips. Presumably any I/O support is part of the FPGA. There are sockets for physical SID chips, but I suppose they can use variable clock speed to interface with those if installed. From what I've read on 6502.org, it gets a lot easier to achieve stable faster clock speeds when most of the system is on a single chip.
  10. I'm working a graphical UI designer for cross-development, but it is very much early days yet. The designer is at best 50% complete, able to add, move, and delete some basic widgets, but not really resize, there is no menu or image support yet, and code for loading the saved design does not exist. The state of the assembly code for drawing and interacting with widgets is no better. Most widgets can be drawn (in some cases, only their borders), but interaction via mouse and keyboard is largely absent yet. Assembly code seems a requirement - I took a first stab at the drawing code using C code compiled with CC65 and the executable came out about ten times larger than the equivalent hand-coded assembly assembled by CA65. CC65's optimization switch only cut about 10% off the size of the executable. And now I know how to write macros and use structs with 6502 assembly and the CA65 assembler.
  11. On that front they should be able to relax somewhat. The repositories are visible in Google search results, but following the links gives a 404 error. Except for the PCB repository.
  12. GeckOS was last released in 2013, but development continues and there were commits by the developer about 8 months ago: https://github.com/fachat/GeckOS-V2/commits/master. A C64 fan has a YouTube video of his presentation at a vintage computing festival, and more info, including a detailed analysis, at https://www.lyonlabs.org/commodore/GeckOS/index.html.
  13. Thanks. Just hearing that it works, I took yet another stab at it. I tried a bunch of different things. Finally, I found that it worked fine once pseudo-register r1, used for the Y-coordinate argument, was at least $0006. When r1=$0000, it was outputting what looked like Morse code in the approximate vertical center. With r1=$0010 it was outputting text about 16 pixels down from the top. Much better. At $0005 or less, but more than $0000, you get what are clearly parts of letters, but with oddities.
  14. Thank you. FYI, you did remember the link when you posted to 6502.org.
  15. Does the GRAPH_put_char kernal call work right? I tried writing out a string and ended up with only a single row of pixels with content in it. Several consecutive calls, for each character in the string, only made the row contain more letters. Adding enough letters eventually did cause it to wrap and the next row ended up with some white pixels. It looks more like Morse code than text. The printString subroutine I wrote to use GRAPH_put_char is below, and a screenshot is attached. I'm not sure if I'm doing something wrong, if this hasn't been fully implemented yet, if the default font is somehow wrong, or perhaps if there is a bug in the emulator. ; Prints a null-terminated string while in graphics mode ; r0 is x, r1 is y, r2 is address of string printString: ; GRAPH_put_char uses r0=x, r1=y for position char, and updates after you print a char LDY #$00 ; index for our string position, max length is 255 chars @loopStart: LDA (r2),Y BEQ @endOfString PHY JSR GRAPH_put_char PLY INY JMP @loopStart @endOfString: RTS
  • Create New...

Important Information

Please review our Terms of Use