Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by TheUnknownDad

  1. 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. 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. 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 loop: LDA $MEMORY_MAPPED_IO_ADDRESS ; 4 ticks 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. I have used the wiki in github to put my first thoughts into words and structure... You might want to have a look.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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...
  15. 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.
  16. Ok, here is our starting point: https://github.com/highno/x16-wifi-expansion I guess we could start with a wiki first to collect information and to streamline ideas...
  17. 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...
  18. That's a great starting point - at least from the software point of view. Thanks for searching and reposting it. I think I will setup a github repo - would that be a reasonable starting point of collaboration to you?
  19. 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 )
  20. 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?
  21. 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?
  22. That's great. Software support is essential - I am still more into software but keep getting better at electronics. Are you already in the facebook group?
  23. 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?
  24. 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?
  • Create New...

Important Information

Please review our Terms of Use