Jump to content

Lorin Millsap

Members
  • Posts

    195
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by Lorin Millsap

  1. As can be seen from above, the function tests if a RAM bank is mirrored in order to figure out how many RAM banks are available. It seems the RAMTAS function needs to be re-written in order to be able to handle that memory is not mirrored. As RAMTAS is a function from the C64 KERNAL, I expect it to be rewritten to handle the fact that missing memory is not mirrored. Since MEMTOP relies on the values provided by RAMTAS, do we need anything else to tell us how much memory is in the system? When a physical system arrives, it might be good to have some software that can actually test the banked memory, but for that I have submitted a fast RAM tester here: A bunch of things in this need to be fixed. So firstly the banking is not handled by the vias. Banking is handled by ZP locations $00 and $01. The emulator does not currently reflect this. The next revision will fix this. And yes missing memory does not mirror so that is incorrect behavior by the emulator. Sent from my iPhone using Tapatalk
  2. Just because a Raspberry Pi is in the ghz range doesn’t mean it’s IO is. I couldn’t find any verifiable info on that but it looks like a Pi3 can theoretically do around 66Mhz. So it might be possible depending on whether it can read entire ports in a single cycle or if it has to read or set one pin at a time. As to CPLD vs FPGA there isn’t a huge difference between them and as to which FPGA the VERA uses that’s not a big deal either. Most FPGAs are gonna be chosen based on your actual needs ie how many macrocells you require. Sent from my iPhone using Tapatalk
  3. I’m sure we can do that. I think it should be an official feature request. Sent from my iPhone using Tapatalk
  4. So use the GEOS headers. Sent from my iPhone using Tapatalk
  5. Yeah. This isn’t going to happen. It’s not needed, for the most part it’s not useful, and we already have routines for loading data into the banks and VRAM. Sent from my iPhone using Tapatalk
  6. You can already load banked data. Sent from my iPhone using Tapatalk
  7. Your question is somewhat vague. So I’m not actually completely sure what you are actually asking. But I’ll try to provide an answer. Chips do come in a variety of formats if you will divided into 2 basic types. Parallel and serial. For the purposes of the expansion bus we are discussing here, it is only directly compatible with parallel type interfaces. Within the parallel type chips there is typically a data bus and sometimes might be an address or register select as we as a Chip Select or Enable and depending on the chip there may be an Output Enable and Write Enable or a multiplexed R/W line. For chips that require separate OE and WE lines you will need to provide the circuitry to split the CPU R/W line into the required OE and WE signals. As to asking if a much faster CPU can be used I have in other articles tried to explain in layman’s terms why this is an issue. It can be mitigated once you understand what the issue is but it’s not as simple as just connecting the buses together. To grasp this you need to think in terms of timing and for my example I’ll use an 8 MHz 6502 and we’ll have a 48 MHz AVR chip. And for simplicity sake we will assume only a single register which can be read and written. How would you interface it? Well for starters you would need to assign 8 of the IO pins as the data bus. Next the CS line coming from the X16 needs to be set up as an external interrupt on the AVR. Since we have only a single register you will not need any address lines. And we can use the X16 R/W line to tell the AVR whether we are reading or writing. So you need 10 total IO pins on the AVR. The X16 can now either read or write to the single register we are presenting. So to understand the timing that will be taking place and we have to allow a margin at the edges because the clocks are not synchronous. You need a margin in the design anyway but more if you cannot guarantee synchronization. So what happens in timing terms when you attempt to write the register. Well we are going to do some quick math to determine what our access windows are. For a 6502 at 8 MHz you take 1000 ns (nanoseconds) and dude it by 8 to get the size of our cycles in nanoseconds. In this case it’s 125 ns. However the 6502 performs accesses in half cycles rather than full cycles so we need to divide that figure in half. Which gives us 62.5 nanoseconds for the access. Next we need to solve for the AVR at 48 MHz. Same equation 1000ns/48mhz gives us about 20 nanoseconds per cycle. So let’s go step by step with what will happen starting with the start of the access window (when the CS line is triggered). This will invoke an interrupt on the AVR. The AVR will need to complete its current instruction so more or less your first 20ns of your 62ns window is taken up. Next the AVR is going to check to see if this is a read or a write access and branch accordingly. This takes a full cycle. So now you are into 40ns into the access. Next the AVR needs to store the value on the data bus which is going to use a single cycle. You are now at 60ns into the cycle and the X16 has successfully written to the register. But there is a caveat. This is assuming the clock edges are closely aligned. In reality they could be up to 20ns off in which case you could add nearly 20ns before the CS/IRQ is registered. This would throw all the actions that follow by the same amount. Since the data on the bus is only guaranteed to be valid for 10ns after the end of the cycle you will in this example possibly work, but it wouldn’t be guaranteed 100% of the time. So this is clear during this action the AVR only has time to execute 2 or three instructions before the access window ends and the data that is written is no longer guaranteed to be valid. So what if the x16 needs to read. Well in terms of steps the AVR needs to get into it IRQ, branch based on the R/W state, and provide the requested data in less than 62ns. But it gets tougher here. The data needs to be valid and stable for at least 10ns before the end of the access window. In this scenario it is just possible if the clocks are correctly lined up but otherwise is a timing violation and will not work correctly. So how do we mitigate this? You need either a faster AVR and by that I mean much faster. Probably in the 60-200 MHz range. What about PIC, ARM, or Propeller? Well the same things apply to each of those. Each architecture will have its own limitations and some may be better suited but it’s still going to be a matter of how many steps can be completed during that access window. Another way of mitigating it is by introducing waitstates. This would be added circuitry though in some cases it could be implemented by the AVR of equivalent. Basically the the CS line is asserted the x16s RDY line needs to be pulled low and held low as long as required. The issue with this is the X16 wasn’t exactly designed with waitstate in mind. In theory it would probably work fine but as of this writing it hasn’t been tested. If this waitstate was implemented in logic it could be done with a counter and a flip flop. If it was done by the AVR you could use one of its IO lines connected to RDY to perform the same task. You would just pull that line low first thing in the AVR and then switch the line back to high when the code is completed. This would have the benefit of allow as much access time as needed. But it has the effective drawback of slowing down the X16 cpu though in most cases it would probably only be a single cycle of delay. As an important not I am making some assumptions about the AVR and that other micros will be similar. I am assuming that the IRQ only takes a single cycle and that you can execute a branch instruction based on the value of an IO pin and that all these instructions only take 1 cycle to complete. If any of these take longer then you definitely have to invoke waitstates. By contrast most of these same tasks can easily be done by a sufficiently fast CPLD or FPGA which is why they a better suited to use on the system bus than a microcontroller. Microcontrollers are better off interfacing to the user port where the timing is much more forgiving. Sent from my iPhone using Tapatalk
  8. Not saying these aren’t valid points, but it is unnecessary. Does it have value. For a multi-task operating system sure. But for a system where each program actually doesn’t have to concern itself with other programs it’s benefits are minimal. Why create special file types when your program can handle its own data just fine and can just put all its relevant stuff in the same directory. Accomplishes the same goal with much simpler code. Also technically parts of GEOS are in ROM and GEOS can do much of what you are describing. We have done some tests and while more work needs to be done in simplified terms we can run GEOS software. Sent from my iPhone using Tapatalk
  9. This topic is already in the FAQ. Sent from my iPhone using Tapatalk
  10. Very nice I think that’s a pretty cool idea Sent from my iPhone using Tapatalk
  11. Just some further updates. I have finished the assembly of the board along with the patches that Kevin has documented. It’s not working yet, and my schedule has been very full this week. I’ve ordered some parts I need to build a test rig, and I have a logic analyzer that I just got. So not much to report yet. But just in summary my test rig lets me get to the very basics and monitor and control many parts of the system. Sent from my iPhone using Tapatalk
  12. On that, the RAM works perfectly. For unpopulated chips there is no wrap around or skip. Reads from unpopulated chips will give erratic results, mostly random residual values. To check how much ram is present you need to write a non-random sequence then attempt to read that sequence back. If the sequence returned matches the sequence written that RAM is populated. Otherwise it is either unpopulated or there is a fault. Sent from my iPhone using Tapatalk
  13. Already been tried. It doesn’t have an effect. Sent from my iPhone using Tapatalk
  14. Sorry I guess I misunderstood the question then. It is a two layer board. Sent from my iPhone using Tapatalk
  15. No possibility of that. Yes it is a multi layer board. Sent from my iPhone using Tapatalk
  16. Indeed. In theory it should just work. But for some reason it isn’t. Sent from my iPhone using Tapatalk
  17. Well actually the schematics for the time being are classified. I of course have a copy, but Kevin has asked me not to share them and I will abide that. I am still assembling the board and then I will apply fixes to known bugs. Then I can start checking things with the scope and also use some other tools to see what I can learn. Sent from my iPhone using Tapatalk
  18. I figured it’s been a while since the last update. So I’m just letting you know where things are at. Kevin has sent me one of the prototype boards in the hopes that we can figure out why certain parts are not working. Timing on the ROM and RAM is stable, the two VIA chips are also stable. There is some odd behavior on the banking latches, and the audio and video are not working. We are certain it’s a timing issue and we will let you all know when that issue is resolved. By sending me a proto board the hope is that we have a second set of eyes since trying to debug it over email and phone calls isn’t very productive.
  19. Very nice. I would like a true parser but that’s probably not going to happen. Sent from my iPhone using Tapatalk
  20. Originally the 816 was our cpu choice but it was dropped for a variety of reasons. Sent from my iPhone using Tapatalk
  21. We are very familiar with this. It’s not something we want. Technically the statement isn’t exactly true either. CPLDs and FPGA have technical differences but those differences have little effect on end results. There are CPLDs that are more powerful and complex than some FPGAs. Both implement programmable logic and the difference is really just how the result is achieved. Sent from my iPhone using Tapatalk
  22. Very valid points. Making it MSDOS like May seem more familiar but will break compatibility with legacy IEC devices which is a design goal even if that doesn’t resonate with everyone. So I think these are excellent points to bring up and any mistakes do need to be corrected. Sent from my iPhone using Tapatalk
  23. The keyboard (and mouse) driver is being improved and yes there are a couple ideas bouncing around on that but the most prevalent is to set the driver to have two modes. The main default mode works like the setup we have now. Then the RAW mode pushes the actual RAW PS/2 data to the buffer instead of the interpreted codes. So to see if a certain key is being pressed you need only check the buffer. However that code hasn’t been written yet as the dev team has been very busy on other projects. Sent from my iPhone using Tapatalk
  24. I’m not posting this as an official update announcement as it’s not finished but wanted to whet your appetites. Also big shoutout to @Michael Steil and @Frank van den Hoef. Frank wrote the main driver which was way faster and more complete than the old one and Micheal extended its functionality. The next emulator release has major improvements to the DOS for the SD card filesystem. The main ones are: A lot of progress has been made with the X16 DOS. It's almost feature complete, and almost has feature parity with CMD floppy and hard drives. • Long filename support • You can open files for reading (OPEN2,8,2,"FILE") or for writing (OPEN2,8,2,"FILE,P,W"), read and write data, have four of them open at the same time, etc. etc. • Overwriting files is done with "@:". • You can copy files (DOS"C:BACKUP=ORIGINAL"), concatenate files (DOS"C:ALL=FILE*"), all with wildcards. • You can rename files (DOS"C:NEW=OLD"). • You can delete files (DOS"S:R*,Q*"). • You can lock/unlock files (DOS"L:R*" or DOS"F-L:R*"/DOS"F-U:R*"). • Like on CMD devices, create directories (DOS"MD:DIR), delete them (DOS"RD:DIR), change them (DOS"CD:DIR). • You can use paths everywhere (DOS"C//BACKUP/:FILE.TXT=FILE.TXT", DOS"$//BACKUP/:A*") • All commands and paths support drive/media numbers (DOS"$1:*"), but only 0 (current) and 1 (only supported partition) work. • You can get partitioning info (DOS"GP"+CHR$(1)) like on CMD hard disks. • You can even read/write DOS memory and execute code in a DOS context (M-R, M-W, M-E). Yeah, not that useful. • All error messages on the status channel (just type "DOS") are consistent with 1541/1571/CMD drives, e.g. 01, FILES SCRATCHED,05,00 etc. What's missing: • Open file for appending (,P,A). • Show/change disk name. • mkfs (N) • fsck (`V') • timestamp support What's missing that I'm not sure should be added: • REL files • block read/write API Sent from my iPhone using Tapatalk
  25. That already exists and it will absolutely work as is. Sent from my iPhone using Tapatalk
×
×
  • Create New...

Important Information

Please review our Terms of Use