Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by TheUnknownDad

  1. 25 minutes ago, BruceMcF said:

    I can't follow the argument  here.  Why do the cards need " bus access" ... for most of them, they will just be accessed BY the CX16. The large majority won't have to "access the bus".

    And after all, part of the point of the Basic/Kernel is that it is NOT equivalent to DOS ... the Basic is running straight on the BIOS. There is no operating required operating system  unless you elect to run one. Otherwise it's like an original IBM PC running Chip Basic when no DOS is installed. The "driver installation" is more along the lines of making the BIOS extensible, in the way the C64 was, except without the extreme RAM limitation and slow mass storage access which got in the way of using that ability.

    When you allow running on the bare metal, how do you enforce expanding the interface logic? Saying "it's not much" when a lot of boards can be two or three chips without the hardware overhead, and provide that functionality in the support software.

    I'm not trying to "shoot down" tbe concepts, just explain why I am skeptical that that approach is going to generate a lot of enthusiasm in a system that is explicitly billed as allowing us to program as close to the bare metal as we want to.

    On the topic at hand, a second approach is for the autostart program to be a sequential file that the system stuffs into the line buffer. It would have to have a reserved channel number, so the programs that are called as a result know not to use that channel number for any information files they use. That solves the subprogram trampling the main program problem.

    Then if there a marker for the end of the line to stuff into the keyboard buffer -- like :: -- then a called program can take parameters from the rest of the line in the same autostart source file. It checks if that channel is open, if it is, it reads the remaining data in the current line. Then the sequential file will be advanced to the end of the line, and if the file is not at its end when execution returns, will stuff another line into the keyboard buffer.

    If I am not wrong, putting data on the data lines is actually accessing the data bus. This would still require tristate logic or am I missing a point? If not, there are the buffer chips... I don't know if the most expansion cards would only accept data and never send data. Is that your point?

    All DOS programs were running on the bare metal, right? They could choose to use some BIOS and DOS functions for I/O but were not bound to it. That was the analogy I was heading to - I didn't try to postulate any equivalence.

    I understand that we look at different segments of a potential market. Having convenience functions, I have learned so far, is always a good idea. Not having to use them is another. You get the ones without explicit tinker knowledge that are "new to this business", but you would definetly lose the enthusiasts if there are ONLY those functions. I would vote for "give people a choice" so they don't need to go the hard way.

    Giving design guides that would guarantee interoperability is another nice option. Why should card builders figure out, which cards users will combine? As to knwoledge there is not a single expansion card available - so no ground is lost. If things are easy and premade like "include this fucntionality or if you don't want to design it, these circuits on your board" - card developers will likely be happy with that. If the bus tristate logic would be needed, there should be a guide to this anyway. I think it would be of much value to have some clever thoughts on this before problems arise and others have invested their time already. 

    Regarding the autostart feature: I think that's worth trying. Sounds good so far, though I'd prefer to have some workflow sketch to follow which steps are supposed to happen when. It helps my mind a lot in understanding and debugging processes.

  2. 4 hours ago, BruceMcF said:

    Cards won't provide a "standard interface". A card might be two VIA chips, a jumper block to select which segment it shows up in, and a quad NAND  to handle the /CS and A4 to pick the correct VIA.

    A card might be a 65xx bus SPI controller and an SPI serial chip. For the first one, the drivers depends on what it is being used for. If it is for a program that knows it's there, maybe all it needs is a small SEQ file that says which device space it is using. For the second one, the drivers will install as the serial device.

    There is no underlying OS to install these cards into, so there is no leverage point to motivate the creator of either card to add any extra hardware. If lots of cards don't t support whatever "standardized" protocol, it's not a standardized protocol, it's just another system that could be used.

    The cards come with one or two binary files that are the driver itself and the driver installation program. The driver installation program can easily be a Basic program, but it might be a binary PRG (whether written in Assembler or C, Forth, Pascal, etc). And a SEQ file with instructions, information about potential conflicts, etc.

    So, how does fixing the problem with running subprograms not fix the problem with a main CONFIG.BAS program? The only task here is to make it easy to add the driver install programs to an autostart program.

    IF the "V2 subprograms trample callers if the callers are smaller" problem is fixed, the main points to "standardize" here are the name of the autostart program and the folder name for holding drivers and driver install programs.

    I am kind of puzzled with the overall thinking about expansion cards. I'd believe, to open up a good eco system for these cards, they should be easy to use and obviously more than one at a time, given the system has 3 ports.

    Since there is likely buffer chips needed for bus access anyway (this is what I understand so far from Ben Eater's video), the extra cost of such an configuration/identification system is likely one ATTiny on the expansion board, maybe a shift register and three logic gates too. As I am a litte late on the development - there is no expansion card reference design so far, right?

    Building an eco system here has been a success to DOS machines too. That is where I see parallels with this machine. You want to make it extendable? Yeah, that what DOS was all about. See that DOS and BASIC/Kernal are mostly of the same use? Of course every program could just try to implement the whole logic for each board it wants to support - but, having Drivers (like TSRs in DOS) they don't need that. They call simple API functions and don't bother about the details. This is where the success story of Adlib and SoundBlaster cards started.

    I'd love to see X16 making its way to a whole retro/future eco system. But in my opinion it needs to be started by setting up the right rules/guidelines to do so. To my believe that is where you sell a real system vs. just a computer. So far "systems" have done better in the market.

    What would be the cost of turning the table and have a hypothetical look from the other side? We could start implementing stuff (and since it is all software on X16 side, the cost of integration later on is "ok") and see where that leads to. Turning the idea down on first sight - just because it may look like feature creep or over engineering - could miss you a chance of finding new perspectives, ways or even small bits of architecture that would actually help.

  3. I need to correct myself. I love Ben Eater's work, and his breadboard computer and video card will surely help me much in designing the expansion card, I wrongly creditted him for the ATTiny Gaming Console.

    It was of course Ben Heck who worked on that. See: 

    Be sure to enjoy also the second part where it all comes to a (positive) end.


  4. 3 minutes ago, paulscottrobson said:

    Is DMA Access going to be a thing with peripherals, specifically Vera ?


    As I understand it, it has only few advantages but many drawbacks. Timing is much more critical. If I got it right, it works by suspending the 65C02 and using the bus all by yourself. That might lead to unexpected results as this could happen at any time, I guess transfer start should be triggered by 65C02 code.

    I am not sure about the speed advantage, maybe someone could help me here: 

    I believe DMA can write one byte to any address (on an active bank) in 1 clock tick, so effectively writing at 8 MByte/s. Using memory mapped I/O this is reduced to the speed of READ,INCREMENT,LOOP cycle, so at best like this - sorry, my 6502 assembler is a bit rusty... 

    (Transfer 256 bytes memory mapped IO with auto decrement on external side):

      LDY #$0
      STA $TARGET_ADDRESS, Y   ; 5 ticks
      DEY  ; 2 ticks
      BNE loop  ; 3 ticks (given that code is page aligned)

    So, transfering would cost like 14 ticks, not using zero page tricks if that is possible. So let's just say 10 ticks optimized - DMA transfer is still at least 10 times faster. Is that true?   


  5. Parameters can be placed in seperate files that could be of SEQ type. All we need to know is, which parameters to put there and which size/format they should have. The driver could then still be a single BASIC or assembler program.

    However, the problem with subprograms would not be solved by this idea.

    I think it would be a good idea to make a sketch a workflow of the whole process in which we could "top down" detail each step further. At the end there should be a full blown workflow of our suggested activities, each part has to do when following that convention. After having identified, which parts need additional software or software changes, we could start working on these and finalize a RC for the expansion convention. Sketching the workflow will also help others to understand, what our intent is and get a better understanding of the overall process. Would that be ok for you? If so, any suggestions where such a sketch could be graphed online, so we all could interactively change it? Would Google be a candidate?

    While reading a note from another user, it came to my mind, that there could be a non DMA, non overlapping solution for the "include a driver in the card" thing:

    On card installation process, when running the installation software, expansion cards could be in a "uninitialized phase" and provide a standard interface for information on the card itself, including an interface to get the built-in driver in a byte-by-byte interface, just like data transfer to VERA works, but in the other direction. The install software can get the driver this way and put it on the SD card. Any comments on that idea?

    I believe, there should be this two phase standardized talking to expansion cards in any way. By using only few I/O RAM spaces for that communication it would also be possible to add this without really implementing two phases on the card, since it could be like first 8 bytes are init phase standard use, leaving 24 bytes for free use without extra cost of implementing 2 phases on the card. If it needed all 32 bytes, fine - the driver should set it to phase 2 mode after finalizing initialization. Again, any comments?

  6. So "initialization" is the process of running initial code and integration of other parts of it for future use in a "Terminate-Stay-Resident" like of way. I strongly appreciate a way of identifying that the driver loaded and initialized ok. So I believe a hook to the kernel in form of a return code including a possible error message would be great. The user likes to be informed that the card will not work as expected. Even more he would like to know what did not work out during this boot. It is an essential part of debugging in real world situations...

    Initial code is "easy" since it will executed once at boot time. Providing an API to be called on demand or even by interrupts is to be looked at too. Again - a good convention would tell e.g. that the code always has to be relocatable and location is given during initial boot phase. Therefore the kernel should know what the driver needs - which is a convention again, as it does not need to be implemented in code. Might be metadata for the installer, which will do that definition of the memory layout for all stay-resident drivers and give that as options to the driver's init code.

    It would be nice to provide a design philosophy to developers which would say: make your device as easy to use as possible, (but not any easier...) - so please provide a BASIC extension which adds high level function calls to access your cards functionality. If that is not possible, provide at least and in any case a "low level" API, namely (relative) entry points to functions, a description for those including how to provide functions arguments. This way the cards functions can be made use of by other users and developers at high or low level. Wait, did we say relocatable code? ok, so how do programs find that location? aahh, there is a kernal call for memory addresses of expansion card drivers, right? great!

    I hope I could make my point clear without any offense. I believe that few functions are needed and a good convention with a test suite for developers.

    Result would be a real product, still fully flexible but more compatible. Why bother to integrate more than one expansion port if no rules are set how to operate more than one card 😉 

    I am eager to hear/read your thoughts on this.


    P.S. You wrote, that you had a chat yesterday - is there a public chat like a discord channel or was that some internal chat only? If it was public, would you mind telling me how to join that? Thanks!     

  7. I really appreciate bringing this topic together in one new thread.

    Also thank you for explicitly describing the hardware environment expansion cards will live in. I hope to see more specs about the expansion ports soon (like pin setup, timing diagrams, electric parameters and later on also size etc...) These specs might already exist somewhere - I am sorry, I didn't search for them yet.

    I think we are already developing a common mindset. I support the main idea, a "driver" is "premade code to provide a higher level API" for accessing functions provided by expansion cards. In my opinion, we should have a look on which "hooks" does a driver need towards the system to integrate nicely. I would say, main aspects of these hooks could be "installation", "initialization" and "usage".

    Installation is where the system should try to seemlessly integrate the expansion card into the system. If the card complies to a to-be-defined standard, it could be identified as a new card, drivers could be searched for, interactively be requested by a system installation software (my favourite). This aspect splits up into: identification of new cards, identification of (and possibly user support on) configuratin conflicts, getting "drivers" into the boot system and configure specific settings for that card/system setup.

    You clearly stated, the selected way so war is dip-switch-like selection. There could be a standard for this, telling people to configure cards in slot 1 to line 1,... This is a guidance not to run into trouble by stting up simple rules. Card developers need to support ALL ids. Again, this is just a convention - and a good one I believe.

    Since I hope, the install/config software is all included (no batteries needed...) I would hope, that there is a built-in way to control the boot process if there are errors (possibly unexpected ones) arising. Like "hold F8 during reset will boot in 'no driver loaded' safe mode". Just to bring in one idea how this could be solved.

    Convention should also tell developers how to tell the installation program, what driver is needed, which options it has, things like this. 

    A convention has the advantage that there could be a reference implentation and automated tests against it. Card developers could then test their implementations before distribution, that rises quality a lot and makes the users happy, too 🙂

    Since things get a litte lengthy here, I'd like to talk about "initialization" and "usage" in the next post.


  8. 8 minutes ago, BruceMcF said:

    That will be however the autoloaded program does it, isn't? Those are all important problems for an autoload program to solve, but if an autoload program has problems solving them, "write a better autoload program" seems to me to be a lot more effective response than "make massive changes to the hardware architecture".

    That is totally true.

    I wasn't initially asking for hardware architecture change. I was asking for details on how that whole expansion system is supposed to work. I already stated that I am desperately looking for information on the whole process of booting and integration von expansion cards in that process.

    Hardware changes are only valid in two cases: 1. something is impossible to realize in software only; 2. things are really, really complicated to solve in software and would be easy with very little change to the design.

    I hope too, that both reasons are no longer valid.

  9. 1 minute ago, BruceMcF said:

    I don't follow "would not bother users to manipulate SD card content." It seems a lot simpler to just have a basic program load things up that you want loaded and set it to be the power up autoload program. This all seems like trying to solve problems the hard way because of some desire to not solve them the easy way.

    I would try to splitt that apart into two aspects: Installing and using.

    I want to make sure that everyone can do both. Many of my questions above in the discussion with Lorin are pointing to the "install" part. I am a strong believer in ease of use. I don't doubt, that getting an autoload program from SD is technically the best solution (as long as it then manages things like installing BASIC extensions & stuff like that).

    How will the "setup" programm  get on the SD card? What does the user need to decide and what does he need to know to use the expansion card? My way of looking at things is to hide all technical aspects but not to make them unavailable. Meet people at their specific level and give them the opportunity to evolve further by digging deeper - but only if they want to.

    Think of "Simon's Basic". As an example, it makes graphics easily accessable - you don't need to know how C64 managed graphical memory. It was "just there". You could also expand things yourself and tamper around with it. But to use it initially, you're not expected to copy anything anywhere, reply to configuration questions, edit config files, change disks, etc.

    Why not make it as easiest as possible to start with? This is what my philosophy is so far.

    If there are other technical ways of achieving the same - be my guest.  I just wanted to understand how to realize it with the possible X16 architecture so I can implement it in a way that could be used as a tutorial/example.

  10. 19 minutes ago, Lorin Millsap said:

    Well the way it works will probably be simple. You install your card, and that card will immediately be able to be used for software that supports it. If you want seamless KERNAL integration, well handling IO is the KERNALs job so extending its functionality through the SD which can be configured to load on powerup will be pretty seamless. You may have to run an installer the first time. Plug and play was not a design goal.

    From my standpoint if the primary storage method was slow and clunky carts and IO mapped ROM makes sense. But when your SD card is about as fast as the CPU can handle it doesn’t make sense to do anything.

    And what happens if you put two cards with a ROM? How would it know which one takes priority? How would it know where to put it in memory without conflicting? On systems like the C64 you had one expansion slot, so you really didn’t have to worry about conflicts caused by two expansion carts. On our design you’ve got 4 physical slots and 5 IO slots they can be mapped to. It does not differentiate which physical slot you put a card into.

    Putting ROM on the expansion brings in all the difficulties of first generation ISA and the endless hardware conflicts that entailed. And the benefits of putting a ROM on the card does not offset the problems it creates when you have a more elegant and flexible solution known as put the driver on the SD card.

    Ok, many points here, let me get into this.

    First of all: Plug and play was or is not a design goal? 

    I understand your point regarding SD speed, I am still looking for that PnP usabililty.

    From what I have heard and understood so far: physically, the system is extendable, but the way extensions are handled in a software way is not yet looked at?

    Regarding hardware conflicts: I don't see the point. It is up to good design, to tell expansions apart. Am I right, that each expansion slot has its dedicated 32 byte I/O area? Or are they simply shared among all cards and you are "not to listen" to other devices I/O by magically selecting a free I/O memory area? So, if there is a way for the card to identify which I/O slot it is in, and there is a clear association, why is there hardware conflicting? We are still in the spec setting phase - so implementation can be regulated. Do it this way and things work out fine. There should also be a way to safely identify all connected expansion cards and the memory slot they are using. Is that already though of and part of the kernel?

    What is the main planned usage of these expansions? Is it to take over the whole system or add special funcionality that ought to be used by either ASM or better even BASIC? If the later, how is the supposed way to add new commands in a compatible way? (so that more then one card can add BASIC commands!)

    Don't get me wrong - this is no blaming or bashing. I just want to point into a certain direction of thinking about the system. I am eager to help if this direction has not yet been thought of. I believe that once the X16 is out, to have a working eco system, these expansion questions should be worked out already. Giving people a ready built example will help to implement new stuff and drive the eco system. It also sets standards to usage.

    If I am all wrong and that expansion system is already all laid out well on hardware and software side (architecture), could you please be so kind to point me to the documentation? That would help me understanding a lot. Thanks.

  11. 13 minutes ago, Lorin Millsap said:

    Yup that is definitely finalized. Wanna load software/drivers? Put them on the SD card. As Adrian shared, the SD load routines are extremely fast. Why bother with ROM when your storage medium is not really going to keep you waiting.


    The only ROM method available via the expansion slots is DMA. However there really isn’t DMA arbitration so good luck with that. Yeah it will work but it’s way more complicated for minimal benefit.

    Thanks Lorin, but isn't installing drivers something we love to not have needed "back then"? As I stated, this approach is very technical and maybe inconvenient for users, even though (or maybe bacause) they are retro enthusiasts. Does the design team have a target user group characterized? Could I find this (or a discussion on that) somewhere? I could learn more about the the product philosophy.

    I imagine this computer should somehow revive that old feeling of "turn it on and let the fun begin". Here is an expansion card - it "just works"(TM). One part of the old fun was. that it was all selfcontained. No need to tamper around with another system to get up and running.

    I am not asking for a design change here - I was asking for the intended use of the system. If that old way of getting things to work would still work, that would be nice and retro too.

    I can skip DMA stuff, if there is a way to get my loader being called at the 32 Byte I/O window and that loader copies all needed code into RAM via the CPU. But that would actually require some kernel function to support this while booting. Just like the old cartridges.

  12. Hi guys'n'gals, ghosts'n'goblins, hobbyists'n'retroists and procastinatists 🙂

    I am a german end 70s born male with a strong addiction to everything that has buttons and lights.

    I started my "career" on a VIC-20 back in 1983 (was 6 then...) and went from BASIC to a C-128 (mostly used in C64-mode...) where I poorly experimented with 6502 Assembler. Leaving 8-bit road for a 386 SX-16 in 1991 and moving over to GW-BASIC and PASCAL, my computers started to add more bits over the years. I used almost any Windows derivate starting from 3.0 to 10 but got an early hang on to alternative systems, so I also bought OS/2 Warp and was a fond linux user since 1993.

    Being the nerd I am, I grew into IT and work as an enterprise IT architect where my design level is more complete datacenter infrastructures  than tiny small IT components.

    My heart and soul being lost in the 80s, I was a retro fan early on and got me a CBM 4032 (now in very poor condition 😞 ) and a CBM-720 (nice design!) around 2000. At the moment, my C128 is sitting right next to me in my mancave, 80s80s radio running and typically Retro TV (aka all these great, entertaining and informational youtube channels) showing on the second screen.

    I started getting into arduino microcontroller  stuff some years ago and liked what I saw and could do with this. Being it ATTinys or ESPs, interfacing the real world seemed very cool. My work is typically much more theoretical... (If you want to have a look: https://github.com/highno )

    I am eager to learn new/old stuff and experimenting with it. Having a set of restrictions, finding a working and possibly elegant solution is what drives me - so 8-Bit systems are just a wonderful world. To give an example: Ben Eater's work on a Invaders-like console with a 6-Pin ATTiny is simply amazing, but also work of CNLohr, pressing out TV signals, color, framebuffer and 3D-Graphics out of a WiFi interface controller design (the ESP8266) is also just amazing. I love demoscene for being extremely creative in art and technique.

    I hope to be able to develop some expansion cards for the X16 - starting with a WiFi network card and possibly an I/O expansion card with BASIC addons so you can tinker Arduino-like with all I/Os, SPI, I2C, etc. interfaces using the card and convenient BASIC commands... (Supporters welcome!)

    I hope to learn a lot of all this and have fun doing it. I love the retro scene and hope to interact with it more - especially while supporting the X16 project.

    • Like 3
  13. I keep editing that post, so here a new post with a new idea:

    To make this also a tinker's dream, let me build an expansion card with some SPI interfaces, some I2C, even I2S, some simple shift registers and even direct I/O.

    You would want to have a nice interface for that, right? Be it some BASIC expansion that abstracts most of the protocol things away. Cool enough? But - why bother the user to install anything besides that card? Things get complex by themselves, so why not keep some things simple?

    Obviously this is a more user convinience driven point of view. But I hope this computer is having its share, it should be overly complex to use - in my opinion. I couldn't really get an answer on what the design philosophy is regarding ease of use/user convenience. Most decisions seem to have a more technical reason so far... 

  14. 23 minutes ago, BruceMcF said:

    Given that the main memory map appears to be finalized, it does indeed appear to be set in stone that there is no ROM window that puts ROM on a card into the address space, unless a 32byte window in the I/O page will suffice.

    There will, however, be User segments available in the flash ROM, so if some card makers want to collaborate on a technique to window into a ROM through one of the 32byte device address spaces and copy code into a RAM bank, then a single ROM image could contain the routines required to do that.

    That sounds interesting. Will there be a kernel function to step through the expansion slots I/O memory areas and check whether there is a card and let that initialize itself (with maybe even copying a ROM into RAM, patching BASIC vector, stuff like that? That would make expansion slot extensions a lot more flexible and would not bother users to manipulate SD card content. It could even be that there is an address to be jumped at per JSR and that byte holds RTS but could actually contain a small boot code?

    We could check whether 32 bytes can make nice init function for expansion cards...

    Kernel could check if there is a magic number in I/O space and then hand over execution of code. It should be possible to deactive this expansion card initialization either via keypresses on reset or via menu/system config. Manual starting of this should also be possible then.

  15. On 7/6/2020 at 4:21 PM, Lorin Millsap said:

    Since ROMs can’t be easily put in the expansion bus there are several methods for handling the driver.


    Method 3 which adds complexity to the card, is that a microcontroller on the card could do a DMA operation and inject code into system memory. During this operation the CPU is inhibited while the microcontroller accesses system memory. While this may sound like an appealing plug and play option it has drawbacks. Firstly making sure it’s code injection plays nice with other hardware and that it doesn’t use memory reserved for other purposes. Also if something does go wrong it’s possible for the card to lock up the system. In reality this method would likely be a real-time compiler so that the generated code could be relocated. It can be made to work, it’s just in my opinion more complex and more likely to cause issues versus loading the driver from the SD card. If it becomes corrupted it would be harder to fix.


    Since I don't have access to any development information right now - is that already "set in stone" that expansion cards are not able to provide their own ROM "on the card"? Is method 3 the only work-around that does not involve adding drivers manually to the kernal or kernal infrastructure? I also haven't looked into that design either - is there public information on that available? Could it be sent to me? I sign NDAs too, if needed... 😉

  16. I am currently in the process of deciding to make an expansion port card using an ESP32 as a network base. If anyone is up to help us - any help especially on the hardware parts  is greatly appreciated.

    My dream is, that Dave could actually connect the Commander to networks from day 1. This would obviously be a major benefit at launch for the machine.

    Actually, we could use this project to make some kind of hardware development example. Hard- and software are thought to be open source. (See 


  17. 4 hours ago, TomXP411 said:

    Hardware actually CAN directly access RAM. It just needs to assert the DMA pin on the CPU. This suspends the CPU and lets the hardware access the bus. 

    However, that's not how I/O devices usually do it. They use something called the Chip Select (CS) pin. 

    Every clock cycle, every device on the bus looks at the CS pin and decides whether or not it should respond to the address and data bus. If the CS for that device is high, that device is allowed to talk to the bus. If the CS is low, that device is NOT allowed to talk to the bus.

    Ok, so will this mode be supported on the X16? I am currently thinking of developing an expansion card for communications. Moving "large" memory blocks (large in terms of X16) is very CPU intensive and requires many RAM access events.

    Is getting next command from RAM/ROM in the 6502 also tied to the same bus at the same system clock? If so, moving a single byte would involve like about 10-12 clock ticks - pausing the cpu would make IO run at least 10x the speed. Am I right to this? And is this possibly supported for X16 expansion cards? 

  18. Hm, how long did it take them to add you to the group? I am waiting for 12 hours now, possibly not much but I want to clear my mind of my ideas. That would work better if I knew, which direction to take. I hope to find some clues in that group. More technical information especially on the expansion port system. Is it worth waiting? 🙂

  19. 13 hours ago, TheUnknownDad said:

    That said, are there more people interested in doing so - and when is the design stable enough so that this interface card can be (at least physical) designed? 

    I try to join the facebook group but there is no answer yet.

    I'd like to see first, if others have picked up this idea already and supporting them would be most effective. But nevertheless - being the Mr. Feature-Creep I am, what would you think should this card support?

    My plan would be to integrate an ESP32 so there are lots of possibilies. Ideas comming to my mind:

    • Act as a modem (not RS/232)
    • having local storage for downloads
    • providing special transfer software
    • act as a cartridge so there is an easy way of accessing special transfer software (if this could be done with these cards - I don't see that from the "specs" so far)
    • Webbrowser proxy mode - do modifications so C64 can handle the site but special features still working
    • support modes for acting as a multiplayer gaming client AND server (offloading the TCP/IP-part of it)
    • provide API for multiplayer gaming
    • support download to (virtual) disk - especially normally attached (virtual) disk drives
    • open source design, software and hardware
    • target price of production:  €25 (sorry, I'm german) for PCB and parts, self build kit
    • ...
    • (please add your features here)

    From the few specs regarding expansion cards that I found so far, there are some questions arising:

    • Ok, we get memory mapped I/O with 32 Bytes, but...
    • can we actually implement banked ROM?
    • can we access system memory directly from the card?
    • ...

    So, who is up to this project?

  20. I am very interested in developing such an expansion card, too. This would be my first pcb(waaaaaayyyy - sorry, Peri...) project. I have done a lot of tinkering around ESPs though I am only an enthusiast.

    That said, are there more people interested in doing so - and when is the design stable enough so that this interface card can be (at least physical) designed? 

    • Like 3
  • Create New...

Important Information

Please review our Terms of Use