Jump to content

Lorin Millsap

Members
  • Posts

    195
  • Joined

  • Last visited

  • Days Won

    13

Lorin Millsap last won the day on October 8

Lorin Millsap had the most liked content!

2 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Lorin Millsap's Achievements

  1. This is incorrect. The VERA is designed so that it’s buss interface is independent of the host clock because we want it to work on other systems. It does not generate the system clock.
  2. This would probably partially work on the X16 with the tricky area being the banked RAM and the zero page mapped Banking registers. If it can be set to externally access $0000 and $0001 as external IO in addition to the main IO range, plus the entire banked range then it would work, but that’s three exception areas.
  3. Well a lot of this is why David put out polls. See if people are expecting a fully assembled unit we don’t have the manpower or logistics. If we assemble them stateside we don’t have the manpower and if we have to assemble them in China there are logistics problems. But if it’s a DIY kit then that really helps. But not everyone is capable. I’m good at soldering and these take a while and it may be beyond a newbie. it seems the majority is fine with units minus cases and requiring users to assemble themselves. For full assembled units expect to pay a premium and have a long wait time. As for the X8 I’m warming up to the idea.
  4. In Bruce’s defense, he is very engaged, so he is a fairly reliable source.
  5. As one of the official team member I will say first. David has not thrown his hands up at all and if that’s how your are interpreted it, that means only that you concluded that first and are only hearing what you already believe and not what he said. Secondly David is really not that directly involved in the technical aspects of the project. Micheal who is handling the KERNAL development has been very busy. For example the PS/2 code issue. I’m not a code guy, but I was aware of the issue and a solution was proposed. But due to tight schedules, hardware changes, etc. the fixed code was never merged so the current KERNAL is using the incorrect code. The reason it doesn’t work with the faster CPU is because the timeout runs faster too and it reaches the timeout before the keyboard gets ready. The code needs to be updated to prevent that. As to other issues, we are dealing with supply chain issues which are not unique to us. You have cargo containers sitting on ships for weeks, you have factories halting production on all but a few lines, the global chip shortages, etc. And another point, for a project that as of now isn’t a crowdfunded project, how many are this transparent. We have ongoing tests with the existing boards are a trying to get enough parts to complete a few more boards. Fingers crossed if it goes well there will be only one more board revision and the project will advance to the preorder stage.
  6. No. The hardware is too different. The only stuff that will convert over with little or no change is text based stuff. It is possible to pseudo mimic the SID. Sent from my iPhone using Tapatalk
  7. Yes and no. Using 256 color mode is unlikely unless your resolution was really low or you figured out how to do it in tile mode. In reality you’d probably drop the color depth and resolution. Sent from my iPhone using Tapatalk
  8. SPI has no strict timing requirements. It should work regardless of system speed. Sent from my iPhone using Tapatalk
  9. Sorry. I missed that. However I think we are already using it in a few places. Sent from my iPhone using Tapatalk
  10. HCT is not faster. ACT is way faster. However as a while you are right. Sent from my iPhone using Tapatalk
  11. In my view the timeout should be removed and a separate system based timer should be used. The same VIA chip has timers and they can be configured to count higher. Also running in a loop defeats the purpose of switching the circuit to IRQ based. The way the PS/2 has now been setup it is connected to VIA0. This VIA has its _IRQ line connected to the CPU _NMI line which means IRQs generated by this VIA cannot be ignored. The theory is that you only use IRQ functions of this VIA for PS/2 related functions. For most software unless you are doing timing critical stuff there is no problem with the PS/2 keyboard generating these NMI events at pretty much any time. It will just read the data as it comes in, and you just disable the keyboard at times when you don’t want interruptions. Normal behavior will be to inhibit mouse except for once per frame if the mouse is enabled. And the mouse and keyboard will have to take turns. Sent from my iPhone using Tapatalk
  12. I’m certainly not an expert on the code. But what seems to be happening is the PS/2 code that was used was written in a poll type interface. PS/2 was meant to be interrupt driven. Because the code is Polk based it inhibits keyboard communication except when it wants to. On a CPU cycle limited system like a VIC20 or C64 where you need to read things within a narrow window of time that works fine. And on our system this is still somewhat the case, except it needs to to be implemented differently. Holding the click line to inhibit communication is not the problem. The problem is the code essentially hits a timeout, and if the keyboard hasn’t started transmitting by the time the code times out, then it misses the data. When it’s run at lower speeds this works fine, but when the CPU speed gets increased then it times out faster. I thought Frank wrote some new code that worked better, but apparently it never got merged in. Sent from my iPhone using Tapatalk
  13. Reality has simple text printing shouldn’t be that hard, but yes you need some type of microcontroller based bridge adapter to translate between say an Epson protocol to a modern printer. Probably pretty steep got Arduino, but a Pi could absolutely do it provided you are running some widely supported Linux host do that it can use standard print drivers. The it could take the source machines text or simple graphics output, convert it to some type of image, probably PDF or ODF and then print that image to a modern USB or network printer. Sent from my iPhone using Tapatalk
  14. The reason it hasn’t been pushed is there are some hardware things having to do with keyboard and mouse handling which haven’t been tested on real hardware yet. However the R39 is there and can be compiled, and so long as you are using Kernal routines it should work. Personally I think R39 should be pushed and if it turns out we need to make some hardware changes we can push out an R40 release. Sent from my iPhone using Tapatalk
  15. There is no reason to support R38 as R38 doesn’t reflect the real hardware. You should shift your code to R39 or have separate binaries as R39 doesn’t have an official release yet. Sent from my iPhone using Tapatalk
×
×
  • Create New...

Important Information

Please review our Terms of Use