Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by BruceMcF

  1. Quite. Without the filters, the bass line on the PSG seems like it would be a bit bland, while the YM2151 is famous for having a nice crunchy bass patch ... even out of the box, where the Bass patch #1 is really the only factory patch that people seem to like. Never mind the benefit of having hardware ADSR for "pew-pew" sounds.
  2. There's an issue to be aware of ... the question here is designing the task files so that they are NOT heavily used as temporary data storage when in the middle of this kind of workflow. Write one, use many times should be the watchword. Of course, the big advantage of having the command arguments in a file is the ability to reuse them, which is why I'd favor the standard channel over the standard filename approach, even before you brought the write cycles issue up. Cycling through a particular argument for text editor, compiler/assembler and then running program would only require a write when you need new arguments. The Menu system would definitely have to be setup so that it is easier to reuse the last set of arguments than to write new ones. But as far as storing the name of the task file that has been opened on the command arguments channel, to enable it to be closed and reopened, if the program wishes, the write cycles issue would suggest that task file name has to be kept in system RAM somewhere, available on request. That is something that would be on a rotation as you work through a project made of the sequence of tasks. One way to organize the task file with the command arguments for a program is to have the task file have the program file to be loaded and run as the first line, and then the arguments on following line. Then the program is run with its command arguments by selecting the task file itself, the Menu opens the file on the command arguments channel, gets the first line, and loads and runs the program ... which then means that the command arguments channel is open on whatever channel it used. So in the Menu, you can re-use an existing task or go through the process of selecting a program and creating it's task. Then a project file is just a list of task files you have selected from the "these are your task files" display, and if you have the menu as your autostart option, when you exit from one project, the Menu program knows you were doing a project file, so it comes up with the next task in the project ready for you to hit return.
  3. Note that these "Rockwell" instructions are NOT in the "65c02 emulation mode" of the 65816. They were also not in the 65c02's from sources other than Rockwell or WDC, but that doesn't mean much since only the WDC chip is still in active production. The SMB and RMB save three bytes and two or three clock cycles over: TSTBIT5: LDA zp : BIT #$20 : BEQ target ... though of course that second pattern is a lot more flexible, since it can use any address mode for the data to test and can test for a set of bits being all zero vs one or more nonzero: TSTLOBITS: LDA (stack),Y : BIT #$0F : BEQ target
  4. Note that several versions of the first design and a batch of the FMX have already shipped. The October dates for the U and GenX boards seem likely to be informed by the experience of building and shipping the first two designs.
  5. You seem to be familiar with one particular approach to passing parameters. I already gave a way to pass parameters: write the parameters into a sequential file, a line per parameter, and have a channel open when the program is launched. Then INPUT# is your friend. That has a second version, where there is a standard name for the parameters, and the program tries to opens that file. Then you have a Kernel call. That could return the address in AY format of a list of arguments. Each argument starts with the number of characters, so the address+1 is the first character in the first argument, which is (address) bytes long, and address+1+(address) is the address of the second argument, until you get to the 0 that signals it's the end of the list of arguments. Then a Basic Keyword that can parse that into a string array and you're good to go. For any of these, a Menu system can have an argument option system built in to pick input and output files and set various settings ... for instance, you might have a standard program description file that the Menu program is able to read might have a simple system for specifying arguments are accepted and what options they have. Arguments were passed to the CP/M and PC-DOC microcomputer single tasking operating systems long before it involved spawning and forking processes. Because the command lines systems were designed for paper teletype first and then glass teletype and menu systems were only designed later, the menu systems were often a kludge on top of the command line interface, but it's perfectly possible to do that the other way around, have an argument system that works using a menu file explorer. Then if people want a command line, someone can write a shell that uses the same argument passing system.
  6. However, the U/U+ boards DO have sound capabilities ... the expansion card adds Ethernet 10/100+ and two SID sockets, but the home page of the Wiki says: What it lacks that the FMX and GenX have is the OPM, OPN, and MIDI in/out. Evidently, from the shop page, the U/U+ are undergoing redesign to work with an FPGA that will be easier to obtain. Since it is sold as a bare board and the "Hardware Enclosures" page doesn't actually give any information on what type of standard case the FMX will fit into ... and gives zero information about enclosures for the Feonix U ... that'd be another reason for not placing an order, even if I had $220 burning a hole in my pocket right now. There's a github for the Basic ... it seems to be in an early development state at the moment. https://github.com/pweingar/BASIC816 And in addition to an early days ports of retroforth, there is a port of open forth 816 (of816) which seems in a more workable state: https://github.com/aniou/of816/tree/C256/platforms/C256
  7. This is part of the thinking in having file selection functions FOR a program being an option in the Menu system. Then whatever channels the Menu system uses and wherever they store the file name and other data, in whatever format they do it, becomes the standard, because any program that does it the same way as the Menu will be usable by any program that takes advantage of the Menu system. One thing about having a (relative to an 8bit system) fast and roomy mass storage option is that we don't actually need to store it in Memory. There could be a standard file, or standard channel that is opened before loading and running a program, with the information in a standard format. And with a file based system, we don't have to fuss about saving RAM space for the system: [input]="filename"[\return]output="filename"[\return], etc. Just parameter_name=string and carriage return, the first parameter by default the name of an input file ... you know it's the default when the first character of the first line is "=". With channel #15 being the command channel, I'd nominate channel #14 being the "commands data" channel.
  8. I figured out something that I found a little cool over the past two days. A core part of the mcode interpreter (see, for example, this pdf scan of the documentation of the mcode interpreter) is the way that relative addressing is handled. 8 of the instructions have an embedded 4bit parameter that refers to the call level of the data, where the outer block if 0, a procedure it calls is 1, and so on, to a maximum depth of 15 below the outer block. The parameter is relative to the current call level, so a variable defined on the stack within the current level would be a parameter of "0", while if the current level is six below the outer block, a variable defined within the outer block would be a parameter of "6". Then there is one or two bytes that give the offset from the base of the stack for that level. The entire start of the stack frame is (the stack grows down): (... locals / working values of calling procedure) [Space for return value if this is a function rather than a procedure] Base Address for this procedure Mark pointer of calling procedure Program counter value of calling procedure (... locals and working values of current procedure...) The way that the Kim-1 code (zip file) did this was the way envisioned in the original language system design. There is a mark pointer that points to the marker position for the current procedure, and the start of the current procedure holds the mark pointer for the procedure that called it, and so on. So you get the mark pointer for the current level, check if the call level parameter is 0, if not, you fetch the value it points to and decrement the level, and repeat until the level count hits zero. Needless to say, this is REALLY SLOW on the 6502 if you are 6 call levels deep and referencing a value created at the base level. But because of the way that Pascal was defined, lots of variables get created at the base level. So what I have sketched instead is an X-indexed stack of call level based addresses. It is a 16 integer stack, so 32 bytes (probably on Low RAM rather than the zero page, to preserve some space for Assembly Language procedures), with the level of the index stored in a zero page byte, LEVEL. The parameter been shifted one left by the time this code is reached, so the parameter is now even numbers from 0 to 30. Add LEVEL to the parameter, put the index into X, and then the base address is available to have the offset parameter subtracted from it. Now, while it does have the characteristic verbose character of 65c02 assembly working with 16bit values, it is MUCH faster in getting an offset computed for anything outside of the current procedure. Now, in the m-code interpreter for the Kim-1, the base address is a dummy, because all offsets are computed by the interpreter relative to the position of the mark pointer. And with this "call LEVEL" stack, the marker pointer on the stack is also redundant. So that means that the program counter to return to is the only value needed for the stack frame. If those two redundant values are removed, this means that the base address is the address of the stack pointer at the time the stack frame is being created. Just store that into the call LEVEL stack. And THAT means that there is no need for dummy base address or mark pointer positions on the main system stack. It can just be: (... locals / working values of calling procedure) [Space for return value if this is a function rather than a procedure] Program counter value of calling procedure (... locals and working values of current procedure...) ... saving four bytes per procedure call.
  9. One of the original boards, the C256 Feonix U, is still for sale on the site for $200, but that is bare board alone. Plus probably whatever four to eight hours of my time sitting through Youtube talks to work out how to get a case that will fit the thing. But unless the plan is to keep that in stock as an entry level, by the time I am back in the US and have a permanent home base sorted out, it will likely be sold out.
  10. If it does, it's much smaller. The sentiment that a cycle exact FPGA simulation of a system is superior to an emulation of a system is well entrenched, but in the end, the key issue is whether there is ongoing release of new software for the platform. The problem with the all-in FPGA simulator of a purely fantasy system is that the project will fork, then fork again, over disagreements in design philosophy. But with the CX16p in the mix, only the forks that are strict supersets of the CX16p get to participate in the programs written for the larger install base made up of CX16p's and CX16c's and compatible FPGA simulators. Those superset forks would be the functional equivalent to a board that has sold to some minority percentage of CX16p owners. Those who get them get whatever their benefit may be, AND ALSO something that "just runs" CX16 software. It's like you have street musicians forming a small group. The guitar and the sax can argue endlessly over which one should tune to the other one, but if there is a penny whistle in the mix, they all have to tune to the penny whistle, because the penny whistle is going to keep on playing at the tuning that came out of the factory. The "as kit buildable as feasible" CX16p system reference platform is the anchor for the design. So, for example, you COULD steal LowRAM from HighRAM, just having five of the HighRAM segments that get selected for LowRAM addresses and not for HighRAM addresses. But doing that logic in glue logic would be much more of a hassle and could well involve too may layers of logic to get the RAM selected in time, given that there simply IS a "fastest commonly available 512K SRAM in a through pin form factor". So that hard availability constraint is like the tuning of the penny whistle: that is not a practical option for the CX16p. They really could do exactly that for the CX16c. When removing the through pin constraint, there are 1MB Static RAM in a surface mount form factor of the same speed as the one they are using. And relaxing the requirement to address things with glue logic is one of their big available cost savings moves that keeps the ASIC CPU, VIA and sound chip. And a surface mount CPLD could easily do that "steal the LowRAM from the HighRAM" addressing trick ... it wouldn't be all that big of a CPLD. So that gives a single surface mount RAM chip, which makes a cheaper build, but still is software compatible with the base CX16p with the minimum one HighRAM chip installed. And for people who go "ewwww, CPLD", you can point to the CX16p ... "yeah, we know what you mean ... if you can afford all of that lovely glue logic, get that one instead."
  11. It is important to avoid overstating things. There are always a lot of different things going on in a real world case, so a single case should never be taken to firmly establish a single point. A single case is always suggestive evidence, rather than definitive evidence. But having said that, AFAICT, the big difference is the team. The combination of the board and the hacking of the C64 ROMs and the emulator have all contributed to the situation where despite a long delay tracking down chip select design flaws, there is much more software developed for a system that only exists as a handful of prototypes versus a system that has shipped two main iterations of the design and is now in the process of developing its "II" version. Most of the team are from the people originally attracted to the first statement of the vision, where the a "no FPGA design" is so strongly stated that a later explanation of "I didn't want to, but in this case there's no alternative" had to be made when the decision was made to go with an FPGA implementation of the video chip. So it seems to me like appealing to that particular market niche bore fruit in terms of attracting many of the people to the team that has brought it to this stage. That is not a criticism of Stefanie: I really like her original Feonix designs, and even if I am not all that interested in the bells and whistles added for the Gen X, if I was flush with cash I would have probably already have bought one.
  12. If you use Pascal booleans, than it's "LDA N : EOR #1 : AND #1" or "LDA N : DEC : AND #1". If you use all-bits-set true, then for bytes, it's just "EOR #$FF". And if you have an 1-8 item bit vector, then it's still "EOR #$FF", as that inverts each bit in the vector, but given that it's a bit vector, the zero flag only tests whether ALL items are false or ANY items are true.
  13. Then also convert the result into methane biogas, and your on the path to energy independence!
  14. I guss I don't actually view them as similar niches at all. The first niche of the CX16e is to simulate one of the real CX16's. Because, after all, simulating a system is better than emulating it. And it seems like it will be able to simulate it to the point of sitting inside a CX16c case and pretending you have a real CX16, which as far as cycle correct FPGA simulations of real hardware goes is pretty good. The second one is the implication of removing all the capabilities you refer to, which will be its education niche if it has one at all: that it is an understandable system. But unless it is a course in FPGA's, it's the real CX16's that are the understandable system, and the CX16e is simply the more affordable simulation of that. As far as whether it ever occupies that second niche ... I dunno. I actually would be skeptical of anyone who claimed to know, because I reckon what it would take would be an established instructor who has a compatible approach picking it up and running with it. And on the one hand, I wouldn't hold my breath, but on the other hand, stranger things have happened.
  15. But what would I care about whether "there software ecosystem" a 65816 card? I would be building/buying the 65816 card to play with it, not to run other people's software. The base configuration would run other people's software. As far as I can see, your concern is that the project started out aiming to build Dave's dream computer rather than yours, given that the workarounds you propose are to NOT have the real ASIC CPU that he wants, or else to NOT have the simple 64K memory map that he prefers. Once you aim for a 65816 with a 24bit address space running in native mode, then the project is going to start adding other bells and whistles and you are at a C256 Feonix board which already has four or so FPGA's. Then that is a system that is never going to be able to be put into an FPGA at whatever price point the CX16e ends up hitting.
  16. How is that anything other than saying that catering to the part of the potential market that wants what you don't care about is absurd because you are not the one who wants it? That it is being done to satisfy somebody else's desires, so it is a mistake? On a side note, I also don't believe that the CX16c will be $700 or 600 Euros until I see it. Granted, it might be $250 in the US but 500 quid delivered to the UK under your governments daft customs policies, but that's not really on the CX16 design team's decisions. As to the extent that the kit-buildable CX16p (whether or not the built from kit option is offered) will be confirmed to have an actual market niche ... we'll find that out when it goes to crowdfunding, but I'm not going to be surprised if it proves to have one.
  17. Why $403-$424? Has somebody yelled dibs on $400-$401?
  18. A compiler would have simply abandoned parsing, as it had unbalanced parentheses, just recently fixed. A notional interest in the CX16e would be the interest with the greatest standing that fits the argument, so for the sake of argument I was prepared to grant it (pending contradiction). One thing about the CX16 project is what appears to be a real prospect of a healthy ecosystem of ongoing hobbyist development for the system. One part of that could well be that it appeals to a variety of different niches. And a system that was perfectly suited to target exactly one of those niches might have some "checklist features" that they like better, but if nobody ever writes any interesting programs for that system, the checklist features don't matter. So if a bit of compromise against my personal "ideal 8bit retro system" is necessary in order to attract interest from that range of interests, I reckon it's probably a worthwhile trade-off. The thing that FIRST attracted me to the project doesn't even seem to be a thing anymore, which is that it was going to use the 65816. However, OTOH, given the expansion slot design, putting in a 65816 card that takes over the system bus looks like it would be pretty straightforward, so even if the surface mount 65c02 for the CX16c is soldered in for cost reduction, as long as it has at least one expansion slot, "swapping in" a 65816 looks like it might still be workable. Indeed, since the 65816 sends the status of the Emulate bit onto a pin (Pin E, 35 in the 40 PIN DIP, Pin 39 in the PLCC, which are NC's in the 65c02), the same CPLD that is handling the takeover of the system bus protocol could trap writes to $0001 and raise the top bit if the 65816 is operating in Native mode, allowing for mirrored Native Mode versions of the system ROM banks ... if, that is, the system ROM banks do not occupy more than half of the System ROM.
  19. When I have something that can be assembled, I definitely will put it up on Github ... right now and for the next couple of weeks, I am still at the puttering around phase. I was able to borrow from xForth for the integer multiply and divide, but using a zero page indirect "LDA (S) : LDY #1 : ORA (S),Y : STA (S),Y : JSR DROP2" stack makes it very much it's own thing versus either SweetX16 or x4th.
  20. Also, I never did much programming in Pascal, and I misread the Kim1 documentation on the m-code and the Pascal model. With the much clearer documentation of the FreePascal code for a generic m-code interpreter, I see that I was implementing the stack and heap the wrong way around. That is not a problem to fix up, though: it is actually easier doing it correctly, since with the (S) in zero page pointing to the bottom of the stack, (S),Y can easily reference all of the bytes in the built in operands -- at most 16bytes for operations on a pair of sets, which are 8byte membership bitmaps for up to 64 items. With the relocatable bytecode allowing for an ability to load a program segment and then recover its space and load another one in other versions of P2 Pascal, I am now leaning toward keeping the HighRAM page available for an external code segment. The procedure and functions that a program refers to are converted into an index number by the compiler, and are called by index number. The simplest way to implement that is to set aside two pages to hold vectors, and shift the index byte, using the carry bit to select between the two pages and the shifted lower 7bits of the index as the index to the address of the procedure/function. So the idea is that if the address of the routine is below $8000, it's a routine in the base compiled code. If the address of the routine is above $8000, it's a routine at a location in a HighRAM page. Requiring it to be loaded at an aligned 8byte boundary means that 15bits can refer to a procedure stored anywhere in the first 1MB of potential HighRAM. Only the procedure and function call and return operations have to worry about whether it is a base or extended routine, and keeping track of which it is at present only requires one byte in zero page that has the #0 for a core procedure/function and the location HighRAM segment. AFAIU, it's not Pascal-M that actually implemented the loadable code segments, but it was done in another P2 based Pascal, so there should be a scaffolding already in place for pursuing that approach: most importantly, already existing example Pascal code P2 code . As far as using HighRAM for data, I am thinking that a RAMdisk is a pretty good approach. In this case, there ARE more developed versions of Pascal-M that have more file functions than Version 1, which has console input and output, a single stored input and a single storable output ... essentially a paper punch or cassette level of mass storage. That makes for an easy to implement RAMdisk at the start, where the program input file is loaded into HighRAM before loading the executable, and the file to save the resulting output file can be selected up front and the saving done when returning from executing the compiled Pascal program. So the program loader is the only part that needs to know how to work with actual CX16 file I/O and incorporating file support into the compiler can be postponed until later.
  21. IOW, @Olegrather than being a provocative question, over the multiple years of the project it is a frequently asked one. But welcome to the project!
  22. The expansion cards include the lines to allow a card to take over the entire bus and access anything on the bus, which is much more than "a very fast parallel I/O system". So it seems you are saying you are in the CX16e market, not the CX16p or CX16c market, and are also sharing with us that it strikes you as comical to be in the CX16p or CX16c markets. That would explain why from your perspective "all it does" to have the kit-buildable system reference design is to scale the price by a factor of 3 or 4 (and by extension, "all it does" to have all the core 8bit components but in surface mount where available (and with other cost cutting design steps like fixed RAM soldered on the board or only one expansion port) is scale the price by a factor of 2 or 3). It's an entirely subjective matter whether or not the design of the Vera is or is not a "next best thing" to the 8-bit style VGA graphic chip that is not on the market from the perspective of fitting appropriately into a system made with 8bit CPU, peripheral chips, ROM and RAM and glue logic. People can share their views and why they have them, but it's not like a technical question with an objectively correct answer. The objective dimension is that the subjective views that are really relevant to the question are the people who are in the CX16p and CX16c markets, since they are the only people whose views on the subject have a direct impact on whether they want to buy into the project. It's fine if our views on the subject are viewed as comical by those who don't care about the question, precisely because those people don't really care about the question, and they will buy into or not buy into the project for different reasons.
  23. Better keyboard, lot more RAM and with the YM2151 a heck of a lot better sound than a VIC, but text display over bit banged serial would be a real blast from the past.
  24. Partly because that is further away from what they wanted than an FPGA wired to be a row buffer VGA chip. If they could have found an introduction ASIC sprite and tile video chip that was appropriate for an 8bit CPU to drive, that would be the video solution. The closest they could find was the Gameduino FPGA design, but that had problems (including being implemented on a very old FPGA), so they put out a call for a new FPGA design. Of course, there are heaps of projects that rely on modern high speed microcontrollers emulating old hardware to be driven by retro CPU's with 1/100th or less the bandwidth of the chip pretending to be its peripherals, there might not be all that much interest in YAPLADYSA (Yet Another Project Like A Dozen You've Seen Already). Part of the point of having the Vera on the separate board in the CX16p platform reference design is so that if it's able to be built from a kit, the builder will only need to put on the connector for the Vera daughter board, and won't have to solder surface mount parts. The cost reduced CX16c would have the Vera circuit on he main board, and surface mount parts wherever it helps reduce TSC.
  25. As far as parallel connection which allows add on CPUs to use the hardware, that's one thing the CX16 has, though there isn't any hand holding on the bus mastering.
  • Create New...

Important Information

Please review our Terms of Use