Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 06/20/22 in all areas

  1. With the Flagship A2560K (keyboard model) now shipping and the GEN X near pre-production completion and about to ship in the next month or two, Stefany Allaire announced a new low-cost single-board computer that checks all the boxes. She took a step back from the WDC 65C816 which has been known to scare classical 6502 bods, and is using the WDC 65C02 running at 6.2x Mhz. The pic of the dev board was just released; Based on the capabilities of prior Foenix efforts, I'm guessing this is a capable platform, and employs enough 'standards' to host the X16 with a minimum of arm-twisting. Stefany has her own Pick & Place machine and is pretty good at parts procurement / supply so I don't see the typical cast of issues getting in her way. I heard it will be < $200 for the SBC (bring your own power supply and PS/2 kbd/mouse ... but also it has a 20 pin Commodore Keyboard header and other gifts; see pic).
    3 points
  2. FASTMATH View File When programming in assembly language, quite often you will need to do calculations that would normally require floating point math. Those subroutines are available, the same ones that BASIC uses, but they are very slow. And if you're programming in assembly, you're doing so because it's much faster than BASIC, so using those routines can defeat the purpose, particularly if you need to do a lot of such calculations. Ideally in assembly language you want to have most of your variables consisting of single bytes, not the five used for floating point. It's having to move all those bytes around and doing calculations involving all of them that makes the floating point subroutines slow. And if you're going for speed, you can make a tradeoff: increased speed at the expense of accuracy. A function involving a single byte can just be a lookup table. Over the last several years I have developed a number of lookup tables and subroutines that enable some very fast math on the 6502 and now 65c02. FASTMATH.BIN is many of them compiled into a single 8kb file that can be loaded into banked RAM. These lookup tables and functions will work on all revisions of the X16 emulator, and indeed will work on any 65c02 system as long as the file is loaded at $A000. The functions are all called through JMP redirects in page BF, and those JMP table locations will not change if I do revisions on the code. I'm pretty sure I killed all the bugs, but some might have slipped through. This is probably going to be the final revision of FASTMATH, barring some sneaky bug hiding in the code. There's only 6 bytes left anyhow. The file fastmath.txt contains detailed information about each lookup table and function and how to use them. The file FASTMATH.BIN is the binary that must be loaded into banked RAM. Submitter Ed Minchau Submitted 06/23/22 Category Productivity Apps  
    3 points
  3. https://github.com/jestin/asmM6502.vim I forked this project from repo that had a single commit 17 years ago, and was only just a mirror of a wiki post. I added 65C02 support a couple years ago, and today I decided to dive in and add a few more things. I don't know who else is doing 6502 assembly coding in Vim, but if you are, this should make it look a bit nicer.
    3 points
  4. I have been seriously looking at building a Z80-MBC2 to play around with for a few different reasons. I never had the opportunity to really play with CP/M, and I always wanted to. It's an inexpensive "retro" computer you can build yourself. It just looks like a lot of fun to play around on. Watching Adrian's SWTPC 6800 videos rekindled my interest in computers of that style and era, and the Z80-MBC2 is cheap modern "DIY homebrew" way for me to have some fun and scratch an itch I have had for some time. Yes, you can do it in an emulator, but this is one case where having actual hardware, getting to put it all together yourself, just makes more sense to me. I mean, I like to build things, so why not? My question is, has anyone here built one yet? If so, what do you think? If not, do you plan on it? I know @BruceMcF mentioned the Z80-MBC2 a while back. I have everything downloaded, the PCB's are on eBay for $9. Or I could order a set of 5 of PCBWay for under $20 if I really wanted to, but, I don't really need 5 boards. I already have most of the supporting electronics and connectors, and tracking down the necessary ICs is pretty simple. The only things I need to figure out yet are the RTC, USB serial, and SD modules. Any suggestions?
    2 points
  5. While years are passing and we all wait and hope to see a finished product to a reasonable cost, what if it would be possible to optimize the emulator and see if it could be included with RetroPie? Together with a Raspberry Pi case with some cool X16 stickers and the already finished official keyboard this would at least be a solitary product. I totally understand if many people find this meaningless because so much is about real hardware but we would be better off than now when we only have the emulator. This would open the possibility to for example build an arcade tabletop machine with X16 games.
    2 points
  6. I have to say that working with the filesystem is one of the most challenging aspects of the Commander X16 that I've personally run across. There are tons of permutations of "Host FS vs SD image", emulator/ROM version, bugs, compiler/system library behavior, etc. One thing that's been updated since R39 is that the hyper load/save hooks have changed a bit, if my understanding is correct - and now instead of just intercepting LOAD and SAVE, the emulator(s) now intercept calls to MACPTR and ACPTR (or some other similar choke point) in order to allow more operations to work with the host FS. It appears that whatever the current methodology is, it doesn't catch everything, because I've recently started working with sequential access to files instead of just bulk loading them into (V)RAM/HIRAM. I've found that this doesn't work unless you're using an SD image. I find SD images to be very inconvenient to work with but hey, I guess that's just the nature of working with something like the X16 in pre-release state (life on the frontier - there's no Dominos and no running water). One thing I've run across is cc65's cbm.h library, which provides what it calls "BASIC-like" interfaces to the low-level kernal file handling routines: cbm_open(LFN, DEVICE, SA, filename) cbm_close(LFN) cbm_read(LFN, buffer* , num_bytes) cbm_write(LFN, buffer*, num_bytes) Where LFN = logical file number, DEVICE = 8 (for disk drive), and SA = that bizarre, multi-purpose byte that is essentially an "argument" for various low-level routines like LOAD or OPEN.... So here we are in cc65 space. The include file also provides three defines to use for the SA in cbm_open(): This leads me to believe that cbm_open() might be doing a little bit of spying on the SA value before calling the underlying Kernal routines. In BASIC, you can use any combo of LFN and SA as long as LFN >= 2 as 0 and 1 have special meaning. I'm going to dig a little deeper into the cc65 sources to see if it's intercepting and interpreting the SA and LFN or not. But the interesting thing I've discovered is that in order for sequential access to work properly, you must use the same value for LFN and SA - and furthermore, these must be 2, 6, or 10 in order for file seeking to work. (I notice that these result in bit 1 of the SA/LFN value being set - hmm) Oh, and seeking - stdio.h implements fopen() fseek() and fclose() - but fseek() won't build on X16 as there's no underlying code for it in cx16.lib - and there's no cbm_seek() function because CBM machines don't naturally support seek (well, without add-ons like SD2IEC or DOS extenders) so the library doesn't do it. To do a seek, I wrote my own function with some advice from @TomXP411 - if you open the command channel to device 8 and send a "P" command (position) while the file is open, Commander-DOS will do a seek. The P command epects binary values to follow it, so here's how to do it in cc65: int8_t cx16_fseek(uint8_t channel, uint32_t offset) { #define SETNAM 0xFFBD static struct cmd { char p; uint8_t lfn; uint32_t offset; } cmd; // open command channel to DOS and send P command. // P u8 u32 (no spaces) u8 is LFN to seek(), and u32 = offset. cmd.p='p'; cmd.lfn=channel; cmd.offset=offset; // can't call cbm_open because the P command is binary and may // contain zeros, which C would interpret as null terminator. // // Roll-your-own inline asm call to SETNAM: __asm__ ("lda #6"); __asm__ ("ldx #<%v",cmd); __asm__ ("ldy #>%v",cmd); __asm__ ("jsr %w",SETNAM); cbm_k_setlfs(15,8,15); cbm_k_open(); // this sends the CMD bytes.. cbm_k_close(15); // close the command channel return 0; // TODO: ERROR HANDLING!!!!! } Note that this code uses cbm_k_open() and not cbm_open() - the k version is a direct Kernal call, so it's not monkeying around with anything like cbm_open might be. Anyway, if anyone has any tips, insights, or whatever regarding file IO, I thought that would be a useful topic for people to be able to hit upon.
    2 points
  7. It's almost 200 times the 31.5kHz horizontal frequency of a standard VGA signal. If that VGA signal's vertical frequency is adjusted to 'drop frame' timing in order to accommodate interlaced NTSC video at 59.94Hz field rate, then the horizontal frequency would drop to 31.4685kHz, and 200 times that would be 6.2937MHz.
    2 points
  8. This is a target that is moving uncomfortably fast in the opposite direction of where they normally go. The FPGA, CPU, and VIAs have shot up ~50% in the last 3 months. The BOM for VERA last month was $30.14 for parts in bulk or $37.73 when buying enough for a single board. I did a pre-price-spike BOM for Breadboard16 back in April; it was $259.72 for everything or $124.92 when costs for things like the solderless protoboards are removed. These prices are for a 512K system and are missing: Mouse, Keyboard, Case, PSU, expansion slots, IEC connector, and SNES sockets. Accounting for the price increases, parts only, including motherboard (~$20 for a 4-layer mini-ITX form factor board) and VERA, comes to around $160 for a 512MB model. PSU is another $25. Case is maybe another $50-75. Keyboard and mouse depend on your preference, say another $25. COTS total comes in around $250-$275 for a base model system. Some broke college kid's time to solder everything together is probably another $150 (7.5 hours x $20/hour), or another $300 if you hire your cousin who can do it "for free". In all honesty, every time I look at the total, I wrinkle my nose and ask "how??", then I look at my BOM with part cost broken out and realize it's just a LOT of parts that cost between $0.50 and $10.00.
    2 points
  9. Here's an entertaining video about Elite the procedural name generation and string tokens part starts at around 5:00 in
    2 points
  10. Just a few months ago I was looking at the RC2014 project. It's very similar.
    1 point
  11. Edit: see correction below. I find it interesting that a Mars probe is running Windows 98. https://www.techradar.com/news/mars-probe-running-windows-98-receives-software-update-after-two-decades
    1 point
  12. "Blue Screen of Death" orbiting the "Red Planet". In all seriousness, no matter what OS and hardware they use, it's vetted and tested to meet requirements and stability that those in the consumer market could only dream about. That's one reason the hardware they often send up is inferior (in terms of raw performance) to what most of us use, that process is long and complex, for good reason. Like @desertfish said, it's often specially designed or modified to withstand the conditions it's going to be exposed to, as well as longevity, stability, power consumption, etc. I always thought it was cool how that process works.
    1 point
  13. Yeah, no ... circumstances have changed from when the project started & I was teaching in China. Right now I am busy with 12 hour shifts, six days a week, so don't have any time for playing with any boards -- and saving up so we can start building our house, so don't have a lot of spare funds either, right at this moment. But I'm hopeful that next year, things will have eased up, and also hopeful that the project will get far enough along to take pre-orders or crowd-funding for the CX16c.
    1 point
  14. The way I see it, the craziness of the parts market has put a lot of retrocomputer hobbyist projects on hold. The Ultimate C64 is unobtainable indefinitely due to the FPGA price. The Mega65 is taking second-round pre-orders, but I doubt they're immune to the FPGA price problem either. Not sure how this one will shake out. The DE-10 Nano for the MiSTer is available but getting hard to find, and going up in price TheC64 (and mini) are available if you're content with a Linux system running an emulator (most people on this forum, even those who bought a TheC64 for the games, probably also want to work outside of emulation at some point). The X16 is in limbo for a number of reasons not necessarily related to the parts market, as I'm sure you're all aware. But Stefany has specifically designed the Foenix Jr. to be obtainable even in the parts crunch; all the parts are currently sourceable at a price that can keep the system under USD $200; the initial target is under $150. A key part of this is the much smaller (and still sourceable) FPGA, which is possible because (1) the CPU is an actual 65C02 and not in the FPGA (unlike the Ultimate and Mega) and (2) it runs a trimmed-down but still capable version of the "Vicky" FPGA found in the bigger Foenix machines.
    1 point
  15. Stefany's productivity is really impressive. She recently got directed to the VERA git repo, too.
    1 point
  16. However, going ahead with EITHER the X16p or X16c requires that the FPGA that hosts Vera is readily available in quantity, which implies that the current ship shortage will have eased to SOME extent. A key -- and in reality not actually knowable part -- is how a shift to a situation where the FPGA that hosts Vera is actually readily available in quantity will be reflected in the price of chips/parts that at present cost substantially more than they did two years ago. In any event, the X16p design has to be finalized ... which means,among other things, available in sufficient quantity for beta testing ... in order to have the benchmark on whether the X16c CPLD (and possibly etc{+}) presents an identical software platform to the X16p. ______________ {+ Note: For example, moving to SMD chips implies a larger selection of SRAM, so one cost reduction might be to have a single 1MB SRAM with LowRAM selecting the top 40KB and 123 banks of High RAM, and one 1MB SRAM will be cheaper than one 512KB SRAM and one 64KB SRAM.}
    1 point
  17. Hmm... I wonder if I can get Bil Herd to sign my VIC-20...
    1 point
  18. 6.29375 = 25.175 / 4 25.175 is the pixel clock for 640x480 VGA. Each of those 31.5kHz scanlines has 800 clocks and 1/4 of that would be 200; so it is also 200 times the 31.5kHz horizontal frequency. Using divisors, especially power of 2 divisors, of a single master clock within a single design allows you to have essentially a single clock domain; this allows you to avoid implementing complex clock-crossing FIFOs for every signal that has to move between the fast and slow domains.
    1 point
  19. The WDCs, since they are 'modern', can easily tolerate a stopped clock or diff clock speeds, of course. The pic above is of the development board which is (I believe) a proof-of-concept that she is putting into the hands of a few developers that will be piecing together the operating environment/kernel, etc. Not sure what form a prod release will take or what the timeframe will be but if successfully released with even 3/4 of the features on that board, it will be compelling.
    1 point
  20. 65c02 only, because I'm using the BBR/BBS commands. And although there are 50, quite often there's only small differences, such as a 2d vector version and a 3d vector version.
    1 point
  21. Version 2 has been uploaded here: I've shuffled some things around and managed to add 14 new subroutines. Two of them are for saving and restoring the data in zero page addresses F0-FF, so that FASTMATH doesn't stomp on BASIC. Four of them are for type conversions between 2 or 3 byte integers and the fractional notation used by FASTMATH (which on reflection is really a sort of floating point notation without the logarithms). There's also a new Clamp function, Determinant, and 4 functions for adding or subtracting 2d or 3d vectors. I also rewrote the ATN function and modified the lookup table it used significantly, and now there are three arctan(x,y) functions available, with precisions of 8, 9, or 10 bits. I've got something special coming soon to demonstrate this in action.
    1 point
  22. 1 point
  23. I've uploaded a new version of my OPL music on X16 demo (VOPLDEMO) to the downloads section. Now, you can play _all_ the songs from the shareware version, and it loads each one into memory dynamically as you switch between them (using the left/right arrow keys)
    1 point
  24. I'm writing a C function that processes banked text with two markup symbols: ASCII newline (0x0a) converts to PETSCII newline (\r\n). ASCII brace "}" converts to a cursor-right character. I'm working on this solution, because it's terribly convenient to edit the text files using a text editor, and at the same time is close-enough to optimal for "externalizing" strings into banked RAM. I'm currently fooling with a method like this: // // Print "externalized" string. // void printBankedText( int address, // location in (banked) RAM to begin printing unsigned char len) // number of bytes to process { char* addr = ((char*)(address)); while(--len) { switch(addr[0]) { case 0x0a: cputs("\r\n"); break; case '}': cputc(0x29); // cursor right break; default: cputc(addr[0]); } ++addr; } } *** BORING DETAILS *** As my Space Trader's binary grows past the 36K mark, I've started "externalizing" string data into the RAM banks. I've found that I can shave 8K off of the binary this way, and that's worth it. The strings are of two types. (1) A few words. (2) Longer, expository text which may be multi-line. *** ORIGINALLY, I processed these string data into null-terminated plain old PETSCII strings. BUT LATELY, I've found it VERY convenient to leave them as ASCII: this makes them extremely easy to edit. FINALLY, though, I have some multi-line, indented strings.
    1 point
  25. This doesn't include all the overheads. A typical "retail" price would be 2.5 to 3x the COGS. If you run it as a one-off Kickstarter project with no after sales support then you could get away with 2x COGS. That puts the price of the base kit at around $500-$550. If you want to assemble and ship a finished product then the costs go way up. You would easily be getting to the $1,000 price point.
    1 point
  26. I created a BOM on Mouser that contained most of the motherboard ICs, and several other big ticket items, hopefully it will paste here correctly. Parts that it does not contain include: YM2151, YM3012, VERA, passive components, PCBs, Mouse, Keyboard, Case, PSU, or SNES sockets. This is for my compatible design which is known to differ from the official design by at least 1 74xx IC. Mouser # Manufacturer Description 652-4607X-1LF-10K Bourns Resistor Networks & Arrays 7pins 10Kohms Bussed $0.56 $1.12 955-W65C02S6TPG-14 Western Design Center (WDC) Microprocessors - MPU 8-bit Microprocessor $10.75 $10.75 806-KMDGX-6SGP-S4N Kycon Circular DIN Connectors 6P/6P PC99 GRN/PURPL STACKED GOLD PLATED $2.41 $2.41 490-SDF-60J CUI Devices Circular DIN Connectors 3 13 Positions, Receptacle, Right Angle, Through Hole, Shielded, Standard Circular DIN Connector $3.19 $3.19 520-TCH357-X ECS Standard Clock Oscillators DIP-8 5V 3.579545MHz $2.90 $2.90 571-1-1775099-3 TE Connectivity Power to the Board ATX PWR CONN 1 BDLK 24 POS $0.92 $0.92 595-TL074ACNE4 Texas Instruments Operational Amplifiers - Op Amps Low-Noise JFET-Input Op Amp $1.12 $2.24 579-MCP7940N-I/P Microchip Real Time Clock I2C GP RTCC,64B SRAM $0.94 $0.94 556-ATTINY861-20PU Microchip 8-bit Microcontrollers - MCU 8kB Flash 0.512kB EEPROM 16 I/O Pins $2.85 $2.85 595-SN74LS06NE4 Texas Instruments Buffers & Line Drivers Hex inverter Buffer/ Driver $0.86 $0.86 595-CD74ACT139E Texas Instruments Encoders, Decoders, Multiplexers & Demultiplexers Dual Line $0.93 $0.93 595-SN74AHCT04N Texas Instruments Inverters Hex $0.71 $0.71 595-CD74ACT20E Texas Instruments Logic Gates Dual 4-Input $1.03 $2.06 595-SN74AHCT02N Texas Instruments Logic Gates Quad 2-Input $0.71 $2.13 595-CD74ACT163E Texas Instruments Counter ICs Sync Preset Binary w/Sync Reset $0.99 $0.99 595-SN74AHCT74N Texas Instruments Flip Flops Dual w/Clear Preset $0.73 $0.73 815-ACH-16-EK ABRACON Standard Clock Oscillators XTAL OSC XO 16.0000MHZ HCMOS TTL $2.71 $2.71 595-SN74ACT10N Texas Instruments Logic Gates Triple 3-Input Positive-NAND gates $0.74 $0.74 595-SN74AHCT32N Texas Instruments Logic Gates Quad 2-Input Pos $0.73 $0.73 595-SN74AHCT138N Texas Instruments Encoders, Decoders, Multiplexers & Demultiplexers Line Decoder $1.01 $1.01 595-SN74AHCT273N Texas Instruments Flip Flops Octal $0.81 $1.62 804-39SF0407CPHE Microchip NOR Flash 512K X 8 70ns $2.24 $2.24 913-AS6C1008-55PCN Alliance Memory SRAM 1Mb, 2.7V-5.5V, 55ns 128K x 8 Asynch SRAM $3.99 $3.99 913-AS6C4008-55PCN Alliance Memory SRAM 4M, 2.7-5.5V, 55ns 512K x 8 Asynch SRAM $6.38 $25.52 955-W65C22S6TPG-14 Western Design Center (WDC) I/O Controller Interface IC Versatile Interface Adapter $10.15 $20.30 571-1-5530843-8 TE Connectivity Standard Card Edge Connectors CONN SEC II 60 POS 100C/L $5.29 $21.16 $115.75
    1 point
  27. Another cost consideration is the move to a single FPGA design. Quadrupling the RAM would likely be much more than a 10% increase in cost. And even with discrete through-hole RAM chips, as we have seen, the market for chips like this has gone whackadoo (I apologize for using such a technical term), with demand outstripping supply by an order of magnitude (or more!), as chip fabs put their limited resources to producing high-quantity, high-profit components for modern systems. Prices for the kinds of chips used in the X16 have doubled in the last couple years, if not tripled or worse! And supplies being how they are, there may simply not be enough RAM chips available to put more than 512k in every unit. We could even be looking at a lottery situation for completed X16 units at first.
    1 point
  28. Based on that, I'd say the extra cost of 3 more RAM ICs to make a 2Mb system the base model is worth it. There are PCB production houses that can put together a board, even through hole, for a lot less than that. I know, I used to work at a couple such places doing just that, and operating the SMT production line. And if we get to the point of making a surface mount version, then we're looking at a lot less than I paid for my VIC 20 back in the 80s.
    1 point
  29. I just had some initial success using MACPTR in cc65. It’s TONS faster and already bank-aware. I’m going to play with it some more but I think it could be even faster if it really will blit in 512 bytes per pass. CHRIN has tons of overhead per byte. will post example code later.
    1 point
  30. I'm using something like that for Asteroid Commander. The tokens are used as lookups to a table in low RAM; the table contains a pointer into VRAM, and individual words or phrases ("would you kindly ") are stored there. The last character in the string has bit 7 set to 1, so BPL allows a loop back to get the next character. I have the strings in VRAM because I'm just moving stuff from one part of VRAM to another, but there's no reason the address pointers couldn't go into a RAM bank instead.
    1 point
  31. It kills 8 bit assembler efficiency.
    1 point
  32. o.O Pointers are the key to C's most powerful features. If you don't use pointers in C, you lost most of the language's capability.
    1 point
  33. One thing to avoid though in C are pointers ...
    1 point
  34. Ian Bell (or was it Braben?) solved this for Elite by tokenizing every string in the entire game. It's a fabulous piece of engineering to cram it all in 32Kb. Not saying that you should do it too, but I find it extremely interesting and was reminded about it by your post
    1 point
  35. Very interesting. Didn't know you also develop in C for the X16. There are some very interesting language constructs that end up with blazing fast 8 bit assembler code ...
    1 point
  36. What is the cost difference for 3 more 512x8 SRAM ICs? 20 bucks US? If it's 10% of the total cost, I'd say it's worth it to make them all 2Mb machines, and make that the lowest common denominator, because the LCD is what programmers will write for. Quadruple the embarrassment! Having said that, here's some assembly language code to determine the max RAM bank number: LDA #FF STA 00 STA A000 SEC SBC #40 CMP #FF BNE #F4 STA 00 CMP A000 BEQ #07 SEC SBC #40 CMP #3F BNE #F2 RTS
    1 point
  37. I didn't get around to checking out the new compiler before now but there is a marked improvement in Petaxian when all enemies are on screen and moving with the latest update. I definitly use a lot of logical expresion and tons of array indexing so assume the above update is why Very very nice.
    1 point
  38. It's extremely minor, and easily overcome. 512k is still an embarrassment of riches for an 8-bit computer, and it means that it can act as a baseline for compatibility, and pretty much any game or application that will work within 2MB can work in some form at 512k. A program can detect the number of banks and load extra data into the higher banks for quicker access. This can make having more RAM act as a cache to mass storage to cut down on load lag. Or extra RAM can enable things like more music and sound effects, so the user experience is enhanced. If a program absolutely needs 2MB to be functional, that would definitely hamper its adoption, and chances are it could have been more intelligently designed to make it work in some form in 512k.
    1 point
  39. 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/
    1 point
  40. Hi Everyone, I am wasPentalive (I was Pentalive in another forum, but I lost the account (email and password fail at the same time ugh) so now I am "WasPentalive" My icon is the R-Pentamino from John Conway's game of life. I was a C64 owner back in the day and perhaps will own an X16 when the become physical - for now, Basic programming in the emulator! Attached is my firs program - It calculates the Colatz series for any given positive integer - If you can find an integer that does not eventually go to 1 you can win a prize (not from me tho) - https://en.wikipedia.org/wiki/Collatz_conjecture . Perhaps I should have put the .prg suffix on? COLATZ
    1 point
  41. Intel 8088 is also an 8-bit CPU since it has an 8-bit data bus. NEC V20 is an enhanced 8088. NEC V30 is an enhanced Intel 8086, but 8086 is a 16-bit CPU. V20 is programmed the same way as V30. V30 is Intel 80186 compatible and has extra instructions and an 8080 mode. I would be rather easy to find V20 developers since they are the same as other x86 developers. V20 and V30 are drop in replacements for 8088 and 8086, respectively.
    1 point
  42. It's that new web schema "total traffic privacy system"..... "ttps;" is brought to you by
    1 point
  43. If so I would add about 4kb more in tables and code and the remaining 4kb would echo the Kernel redirects and JSRFAR etc from bank 4.
    1 point
  44. You could also learn some HDL and invest in a Tesirac DE-10 Nano, possibly a few hats and a case, and try to implement it as an FPGA softcore. Then, once the basic chipset is solidified, you can progress to the necessary OS, BIOS, Language, and Driver code, and then whatever peripheral and interface ports you want to add via USB and dongles. Once you get all that solidified, you've taken roughly 75% of the guesswork out of designing a motherboard. Then, assuming you've stuck to (relatively) available chips in your softcore, you can either send the Gerber file you've confident enough with to PCB Way, or raise money and invest in a Nano-Dimension Dragonfly PCB 3D Printer, and begin assembling and testing prototype boards...
    1 point
  45. In a perfect coincidence, I just created a Hello World repo exactly for the purpose of helping folks use the cc65 tool chain. I have examples in assembly, C, and a mix of both. And the README goes through the whole setup and build process in detail. Get started here: https://github.com/SlithyMatt/x16-hello-cc65 I'm going to be making a video going through it very soon. It may be up as early as tonight.
    1 point
  46. Voyager is basically equivalent to a C64, but a lot harder to program.
    0 points
×
×
  • Create New...

Important Information

Please review our Terms of Use