Jump to content

Scott Robison

Moderators
  • Posts

    829
  • Joined

  • Last visited

  • Days Won

    37

Posts posted by Scott Robison

  1. I do wonder how it could look on a C64 if taking advantage of some memory expansion. I wouldn't be able to use the MMU to speed up block copies, and I wouldn't have a second screen for a map. Also, we never used 2 MHz mode so that is not an issue.

    It might be fun to try to make a 64 version that uses REU (or geoRAM or RAMlink or whatever) to see if it is possible.

  2. No need for crow, unless you really like it!

    When I first started working on this, my thought was to keep it true to the PET / C64 version legacy. It would have been a really pale imitation of what it turned out to be. David got excited about doing more and I was along for the ride! It turned out even better than I thought it would when I first pitched the idea.

    • Like 1
  3. On 11/12/2021 at 8:50 AM, rje said:

    I'm in neither category, and you're right, I'm probably a niche in the niche

    Well, I did simplify it quite a bit. Most analogies fall apart at some point, and mine did. I think your desire still puts you in the tech loving crowd. Even if you don't want to understand the hardware at the chip level, the fact that you are willing to live with the limits of the tech and desire for good tools for it definitely excludes you from the "just web browsing and word processing" crowd.

    • Like 2
  4. But I will say this: I think David has been clear that while Commander X16 is his idea of a dream computer, he's not the one doing the great bulk of the work. He's a bit at the mercy of variables beyond his control for X16 (while having spent five figures out of pocket to help push those variables along; that's not me sharing confidential information to be clear, that's what he wrote in the August info thread / poll). In contrast, he does control most of the variables for PETSCII Robots, so more news flows from that as he is more in control of that (realizing that even then, some people who commit to do a port fall through, and he does overestimate the appeal of the game in some quarters, such as Apple II).

    He's taken a bit of a gamble with all of the ports that he sells, and it's not fun to lose money on a venture. Hopefully with time he'll inch up the 87% or whatever to 100% and hit break even (or better) for what is undeniably a niche product in the year 2021.

    BUT COMMODORE 128 HAS A COOL GAME AND I WAS PART OF IT, SO YAY! 🙂

  5. If you create a file ca65test.asm that includes the code from above and assemble it and create a listing, it shows:

    Quote

    000000r 1               .data
    000000r 1  01 02 03     values: .byte 1,2,3
    000003r 1               .code
    000000r 1  AD rr rr     lda values+0
    000003r 1  AE rr rr     ldx values+1
    000006r 1  AC rr rr     ldy values+2
    000009r 1               .data
    000003r 1  74 68 69 73  msg: .byte "this is a test"
    000007r 1  20 69 73 20
    00000Br 1  61 20 74 65
    000011r 1               .code
    000009r 1  EA           nop
    00000Ar 1  EA           nop
    00000Br 1  EA           nop

    Note that the rr byte values are unknown because we won't know their final value until we link the object file into a program. On line 1 it shows offset 000000, as that is the index into the current segment at the beginning of that line. The ".data" directive doesn't generate any bytes for the program, so that offset 000000 is unchanged on line 2. Line 2 created three bytes, so on line 3 the offset has changed to 000003, where ".code" changes the segment, so on line 4 the offset is back to 000000 because it is a different segment.

    The linker will take that object file (and other information) and create a binary file that could look something like this:

    Quote

    AD rr rr    ;lda values+0
    AE rr rr    ;ldx values+1
    AC rr rr    ;ldy values+2
    EA           ;nop
    EA           ;nop
    EA           ;nop
    01 02 03     ;values: .byte 1,2,3
    74 68 69 73  ;msg: .byte "this is a test"
    20 69 73 20
    61 20 74 65

    The link reorganized the segments so they're in a "good order" for the machine so it can start executing the program and all the code is together, and all the data is together after the code.

    Again, this is just an example for illustrative purposes. 

    • Thanks 1
  6. On 11/6/2021 at 10:01 AM, C3c said:

    Hi Everyone!

    Like many other people around here, I'm using the CA65 assembler to develop for the X16. One thing I don't really understand is what the .SEGMENT command does exactly. I find the CA65 documentation a bit terse on this matter:

    Could any tell me what exactly happens if I use .SEGMENT "DATA" inside my code?

    Thanks!

    Cedric

    A program is a sequence of bytes and you determine how they are used. You can interleave code and data however you want.

    A segment is a way to organize the program more effectively. I'm not an expert with ca65, so this isn't a perfect example, but imagine you have something like this (useless) example:

    .data
    bytes: .byte 1, 2, 3
    .code
    lda bytes+0
    ldx bytes+1
    ldy bytes+2
    .data
    msg: .byte "this is a test"
    .code
    nop
    nop
    nop

    The first line says "stuff that comes after goes into the data segment". The data segment is just a sequence of bytes.

    The third line says "stuff that comes after goes into the code segment". The code segment is also just a sequence of bytes.

    The seventh line switches back to the data segment. Anything that comes after that is appended to whatever is already in the data segment.

    The ninth line switches back to the code segment. Anything that comes after that is appended to whatever is already in the code segment.

    So after assembling that file, you have two segments, CODE and DATA.

    The data segment will have 17 bytes: $01 $02 $03 and 14 bytes representing the text "this is a test".

    The code segment will have 12 bytes: 3 bytes for the LDA instruction, 3 for LDX, 3 for LDY, and 3 NOP instructions.

    You can have multiple source files that all use the same segments. When the linker creates your final program image, it will put all the stuff in CODE together, and all the stuff in DATA together, and the linker configuration will determine which segments come first and which come last (or in the middle if you are using even more segments).

    In the end, segments allow you to write your code in a way that is organized for humans to read it, but that will be better organized for the computer later. This is especially useful when you are writing code that will be eventually burned into a ROM. You can't just intermingle code and data, so in that case you can have CODE that is read only and suitable for a ROM, and DATA that is writable and sitting at some RAM address.

    You can do all of this without segment support in the assembler, but segments help you do less bookkeeping.

    I hope that helps.

    • Thanks 1
  7. All good variations on the theme. I think a serial terminal would be a great solution for that use case, just need a little logic (if on the IEC bus) to make it a "smart" device that "just works" with the C64 (or other IEC capable computer).

    I've seen many solutions to a second screen that used the expansion port, but never anything that acted like a printer (or plotter). A "glass printer" would be nice on device 4 or 5, and a "glass plotter" on 6 or 7.

  8. I was in a conversation at the MEGA65 discord server where someone was talking about other cores they'd like to see made available, as MEGA65 is FPGA and can take on multiple personalities. C128 came up, which is near and dear to me.

    The MEGA65 has two video output ports on the back, an "IMDH interface" (non trademark encumbered equivalent of HDMI) and a DB15 VGA interface. They both show the same screen in the MEGA65, but since it is FPGA, there might be a chance they could actually support two different output signals if the core supported it. That is unknown, but an interesting thought.

    Bringing it back to Commander X16, I mentioned that there has been discussion of putting VERA on an expansion cart for C64 or other expandable systems. MEGA65 has a C64 compatible expansion port so it seems to me it *should* be possible to plug such a beast into MEGA65 and have it work, maybe.

    While we were talking, I had two thoughts come to mind for display expansion. The first one was Commodore 8-bit computers and similar "compatible" systems like MEGA65 & X16, will have an IEC serial bus for talking with external drives and printers.

    Why not create an IEC serial "printer" that is actually a second screen? It would be slow, yes, but I can imagine ways to use it that would be very useful, such as debugging output while the VIC is busy with the actual application. And since the IEC bus supports daisy chaining, it could support more than one such display if desired:

    10 OPEN 4,4
    20 PRINT#4,"HELLO DISPLAY DEVICE #4"
    30 CLOSE 4
    40 OPEN 5,5
    50 PRINT#5,"HELLO DISPLAY DEVICE #5"
    60 CLOSE 5

    Then I had another idea. We know C64 & C128 supported RAM expansion in various ways. 1700 series REUs, GEORAM, and RAMLINK to name a few.

    What if in addition to that functionality, those devices also had one or more monitor connections such as IMDH, VGA, or some such. My main workstation at home is a four monitor rig with two landscape monitors front and center stacked on top of one another, and two more portrait orientation monitors to the sides. It would be interesting to have such a setup for a C64 or other system.

    • Like 1
  9. The biggest problem is that there are two (in general) audiences that use computers. There are the technical people who love to use and understand the internals, and there are those who just want or need to use it as a tool. People who only have an interest in web browsing, word processing, etc, want cheap and fast. The rest of us need them to be secure so that we aren't all paying for their lack of knowledge. Most of the lock down of tech has been security related, though there is plenty of "trade secret" and "walled garden" and other stuff at work as well.

    In the 80s, the 8 bit computers weren't powerful enough for most people to find them compelling. Now they are and there is far more to accomplish with them.

    But I am in agreement with you. I'd like to have both worlds: low level access that allows me to do whatever I want with the computer I own, and high level access that allows me to get stuff done. They don't have to be mutually exclusive, even though they often are.

    • Like 1
  10. On 11/2/2021 at 7:30 PM, Tatwi said:

    I think you're selling that hardware a little short there. Back in the early 2000s I used "Basic Linux" (Slackware 7.1 base on two floppies with custom kernel) on a 25MHz 486SX and it ran all the command line stuff well (X was generally awful back then so I just used Win95 on that machine). A stripped down Linux kernel with Busybox, BASH, TCC, nCurses, SDL, VIM, Emacs, and Nano would utterly fly on that dual core 133MHz ARM CPU and 512MB RAM would be waaay more than enough for programs made in C. FreeBASIC is also available for ARM.

    I've done a fair amount this with my Pi Zero W over the years, but I put it aside to explore retro stuff. Truth be told, if we're talking command line only, I actually prefer Linux over DOS and 8 bit systems, because it's more capable, extensible, and doesn't require assembly to achieve great performance.

    It's funny, a few years ago I started work on a BASIC shell for the Linux kernel on the PI Zero, written in C. I didn't get very far before I moved on, but hey, great minds think alike, eh? 🙂

    Oh, absolutely there is no comparison to the power of any of those two sets of hardware. It was just a list that amused me. 🙂

    • Like 2
  11. On 11/2/2021 at 8:15 AM, x16tial said:

    The difference in my mind is that it wouldn't be an emulator. It would have a kernal written in ARM instead of 6502, and a BASIC in ARM instead of 6502, and would land at a full screen BASIC editor. Direct access to the system with peek and poke, ability to load and run BASIC and ML programs, ability to access the hardware directly.

    I'm not suggesting it would be easy, that I've started it, or that it will be available soon. Just a fun idea for Qommodore. 🙂

  12. On 10/31/2021 at 3:19 PM, TomXP411 said:

    There isn't a single FPGA X16 yet, but all of the components in the X16 already exist as parts of other FPGA projects. So the hard work would really be in combining those into one system.

    Still... since we've been asked not to port the Commander to other hardware platforms, we should probably end the conversation before it gets locked. 

    Agreed, though I do think there is a difference to this question. Namely: I infer "has the X16 team considered using an existing hardware platform as a target for their FPGA X16 version?" as being the question. It may be that Cloanto only licenses the code to go with bespoke hardware, since they sell C64 Forever themselves. I posed a similar question to MEGA65 and the impression is that they are only authorized to include Commodore derived ROM with their physical hardware. More to the point, I wondered if one could sell a core that would allow money to be collected to be sent to Cloanto for a licensed ROM, and the answers I got indicated that wouldn't be possible. If that is true, they could create a cost reduced MEGA65 that didn't include the keyboard or FDD or other non-essential pieces of the system and include firmware with that, but they they probably wouldn't be able to sell a binary core that could be installed on MiSTer.

    Given that MEGA65 has to get the license from the same source as Commander X16, it is probably safe to say similar if not identical terms would apply.

  13. I don't know if the rules have changed recently but I got a warning months ago for even talking about such topics.

    The biggest problem is one of licensing and paying Cloanto for the ROMs used as the base of the X16 firmware. It would be possible to sell a core that came with licensed ROMs depending on the license terms which we don't know. It would also be easier to pirate.

    But technologically speaking, it is a course the team could consider if they were so inclined. Just a lot of moving parts to orchestrate.

  14. During one of David's videos he interviewed several YouTube celebrities when announcing his dream computer. A lot of their answers resonate with me.

    One reason is simplicity. The machines can be understood completely by one person. One person could program the computer without needing a team of specialists.

    Another reason is platform stability. If you have Windows 10 or Linux or MacOS you have a moving target of sorts. 8 bit machines were usually made for years and remained compatible through their life. Not that compatibility is impossible on modern platforms, but it is still a moving target.

    Clearly new systems aren't all bad. We're using them after all. But one can get a lot done with the old systems, far beyond just gaming. The newer technology is just so inexpensive that it is cost effective to write memory hungry inefficient applications.

    I think there is a certain charm to the look of older stuff, but I think that comes somewhat of being of a certain age. Some people gravitate to old cars or furniture or whatever. We appreciate old tech. When we are gone, future generations will look back fondly at today's state of the art.

    • Like 5
×
×
  • Create New...

Important Information

Please review our Terms of Use