I've been using microcomputers for nearly fifty years. I owned several different American 8-bit computers during those early days. I first learned BASIC on a PET 2001 with the terrible keyboard and built-in datasette.
I regret letting go of some of the 8-bit systems I used to own (I have none now, unless a Flashback Atari 2600 counts), and the X16 is a way to recapture some of that. I'm also thinking of acquiring an Agon for the Z-80 side of things. I never did own a 6809-based system, but haven't decided what I might do in that direction, if anything.
One thing I wonder is how the near-certain imposition of tariffs on imports will affect pricing of the X16 and its accessories.
Another thing I wonder is how to get a look at the VERA source code, because something I'd like to see in the line draw helper is a way to have the function invert or increment the color of pixels as it draws.
Hello from Oklahoma
Re: Hello from Oklahoma
Welcome! Glad to have you here.
In addition, the X16Community organization also contains the source code to the Kernal ROM and everything else, plus the technical documentation.
Someone else will need to answer the question about pricing though.
The VERA source code is in Verilog can be found in this Github repository.8_bit_memories wrote: ↑Fri Nov 15, 2024 11:45 pm Another thing I wonder is how to get a look at the VERA source code, because something I'd like to see in the line draw helper is a way to have the function invert or increment the color of pixels as it draws.
In addition, the X16Community organization also contains the source code to the Kernal ROM and everything else, plus the technical documentation.
Someone else will need to answer the question about pricing though.
- ahenry3068
- Posts: 1144
- Joined: Tue Apr 04, 2023 9:57 pm
Re: Hello from Oklahoma
I don't know how pricing will be affected in the future. But there is a production run now and pre-orders are open at TexElec.com. I think they will be shipping NLT than January, Possibly even beginning by the end of the year.8_bit_memories wrote: ↑Fri Nov 15, 2024 11:45 pm I've been using microcomputers for nearly fifty years. I owned several different American 8-bit computers during those early days. I first learned BASIC on a PET 2001 with the terrible keyboard and built-in datasette.
I regret letting go of some of the 8-bit systems I used to own (I have none now, unless a Flashback Atari 2600 counts), and the X16 is a way to recapture some of that. I'm also thinking of acquiring an Agon for the Z-80 side of things. I never did own a 6809-based system, but haven't decided what I might do in that direction, if anything.
One thing I wonder is how the near-certain imposition of tariffs on imports will affect pricing of the X16 and its accessories.
Another thing I wonder is how to get a look at the VERA source code, because something I'd like to see in the line draw helper is a way to have the function invert or increment the color of pixels as it draws.
-
- Posts: 34
- Joined: Sat Feb 19, 2022 4:44 pm
Re: Hello from Oklahoma
The way FX works takes advantage of the hardware design, particularly the way the SRAM can be accessed by the FPGA.
It can write to a nibble at a time without affecting the adjacent memory, which is why 4bpp mode can work so well with it.
If you were to introduce a trick to *modify* data by writing a value based on its previous value, then you're introducing a fundamental change to the way it would have to work, as it would need more clock cycles to read, modify, and write back, and would introduce new complexity in the VERA design. It might not even be able to keep up with the CPU writing to VRAM if it had to contend with that also.
We're up against two main things that would make this ask difficult
1) FPGA/hardware design is fundamentally different than writing code for a CPU. If something takes more clock cycles, it changes the way that that module interacts with everything else that runs in parallel, and could easily require refactoring other code.
and even more so:
2) The VERA bitstream has nearly maxed out the size of what the FPGA can work with. We're basically out of gates, save for a small safety buffer that we may need to use to fix bugs while still having room for all of the existing VERA features.
That being said, if you want to look at the Verilog, you can find it at https://github.com/X16Community/vera-module/
It can write to a nibble at a time without affecting the adjacent memory, which is why 4bpp mode can work so well with it.
If you were to introduce a trick to *modify* data by writing a value based on its previous value, then you're introducing a fundamental change to the way it would have to work, as it would need more clock cycles to read, modify, and write back, and would introduce new complexity in the VERA design. It might not even be able to keep up with the CPU writing to VRAM if it had to contend with that also.
We're up against two main things that would make this ask difficult
1) FPGA/hardware design is fundamentally different than writing code for a CPU. If something takes more clock cycles, it changes the way that that module interacts with everything else that runs in parallel, and could easily require refactoring other code.
and even more so:
2) The VERA bitstream has nearly maxed out the size of what the FPGA can work with. We're basically out of gates, save for a small safety buffer that we may need to use to fix bugs while still having room for all of the existing VERA features.
That being said, if you want to look at the Verilog, you can find it at https://github.com/X16Community/vera-module/
Re: Hello from Oklahoma
What's "NLT"?
- ahenry3068
- Posts: 1144
- Joined: Tue Apr 04, 2023 9:57 pm
Re: Hello from Oklahoma
-
- Posts: 3
- Joined: Thu May 30, 2024 11:59 pm
Re: Hello from Oklahoma
So to do this without affecting existing services would mean a completely separate execution path, and there's not room for it.MooingLemur wrote: ↑Sun Nov 17, 2024 7:09 pm If you were to introduce a trick to *modify* data by writing a value based on its previous value, then you're introducing a fundamental change to the way it would have to work, as it would need more clock cycles to read, modify, and write back, and would introduce new complexity in the VERA design. It might not even be able to keep up with the CPU writing to VRAM if it had to contend with that also.
We're up against two main things that would make this ask difficult
I'm still interesting in looking at how it does things, and appreciate the links.