Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/16/21 in all areas

  1. We've always been open with you about the Commander X16 project's progress, and today I'm sharing my decision to take a little step back from the project. When David kindly invited me on board, I accepted on the basis that approximately a 1 year prototype development process was envisioned for a cased computer, after which I would refocus on my own projects. However, of course I understand these things often do become much more complex, and so I have been happy to give an additional 1½ years to such a cool project. Over those 30 months I've been honoured to be able to give my time overseeing parts of the jigsaw puzzle including the "X16" name, logos, keyboards, manuals, box & cover art (I hope one day you will see it!), social media, factory negotiations, Cloanto ROM licensing, slogans, draft crowdfunding video, 3D renders, X16P and X16C case designs, and of course the website & software library ecosystem for the project to hopefully someday flourish within. I’ve greatly enjoyed working with some very talented contributors in some of those areas - thank you so much Anders Enger Jensen, Charles Paek, Gaz Marshall, John McDermott, Lorin Millsap, Matt Grandis, Mat Recardo, Trevor Storey, and more. However during that time my little YouTube channel has continued to grow beyond expectations, associated writing for ZZAP! 64 has increased, I've started projects of my own such as the forthcoming PETSCIIBOARD™, and have found my available time for prolonged outside projects reduce. Then, sadly my mother passed away very recently, which is now absorbing an unanticipated amount of my time and emotional energies, and I am needing to focus more intently on family matters. I always wish to do my best for everyone, be it fellow X16 fans, supporters, or family, and by spreading myself too thin for too long, I can't be my best for you guys. So, with much of my X16 work recently completed, now feels like the right time to pass the baton. David and I remain friends, and I have wished him the very best of luck with whatever shape the X16 takes post-Peri! He and the team have my agreement to continue to use as much or little of my contributions as he chooses including the case designs (should that be "the case" ahaha), and I remain available to hand over and tie up loose ends. [Edit: Case FAQ] I will continue to follow the X16's progress as a fan alongside you all, and I am sure the project will endure. Thanks for reading my new novel here, and for your understanding with a difficult decision. Long live the Chickenlips 16! Peace out and cheerio! Your friend in retro, Perifractic P.S. If you're not already, feel free to come follow me elsewhere and we'll continue to have fun together keeping nostalgia alive one video at a time. You can find me at: The Tube of You: http://youtube.com/perifractic Facepoke: http://facebook.com/chrisimpsonline Instaface: http://instagram.com/perifractic Interwebs: http://perifractic.com PETSCIIBOARD™: http://perifractic.com/petsciiboard Patrón: http://patreon.com/perifractic
    7 points
  2. Latest video from the 8-Bit Guy includes a small X16 update and demonstration at the end.
    5 points
  3. TomXP411 said it all so well - all I can say is he spoke for me too. All the best to you and your family.
    4 points
  4. Thank you for your kind and thoughtful words. It means a lot.
    4 points
  5. Peri, the project was better for having you in it. And I can honestly say my life is a little better from your creative efforts. I look forward to each new video you create, and the other projects you've created are fascinating. (I still tell people about the Brixty Four...) Your calm demeanor, your sense of humor, and your creative efforts are like water in the desert for nerds like me. I know all about losing family members and the other pressures life throws at you - and I know you can and will not just handle them, but thrive. I'll follow you everywhere I can, and I've already joined your YouTube channel. You're an amazing person and a shining light in the world. Stay Retro and stay classy.
    4 points
  6. I've been playing around with the x16 over the last couple of days and I'm loving every minute of it. Here's a sample of my first interrupt proggy on this platform... https://imgur.com/a/VZ7FkPi
    2 points
  7. Version 0.0.0.7

    48 downloads

    I leave this here mainly for me to play about with when not at home, and also to see if it works on the web emulator. It does not yet function as a game, but as development progresses, I will regularly update this to track its progress. Controls: W, A, S, D to move. Hold down for running.
    1 point
  8. Good to know, thanks for that info. Which does confirm what I thought: It isn't widely implemented though it is implemented for X16. When it comes to a library implementation though, the typical model is "the standard library is implemented in terms of a platform specific library". For fseek, that would mean using a posix function like lseek. For CBM DOS based libraries, fseek would be based on something presumably called cbm_seek (that would be implemented along side cbm_open / cbm_close / cbm_read / cbm_write). But there is no such function. Now ... that is not to say that it can't be done anyway. Clearly it can, but it will require some considerations of "how do we implemented seeking in the cc65 library to support X16 when all the cousins don't support seeking". Library functions that are intended to be general purpose and work across a range of scenarios have different implementation / dependability criteria than other functions.
    1 point
  9. For FAT32 support, @Michael Steil implemented "f32_seek" a year ago. It also looks like he added a "P" (= Set Position) DOS command, borrowed from SD2IEC, that hooks into f32_seek. https://github.com/commanderx16/x16-rom/blob/master/test/dos.bas Note the erroneous line number between 4828 and 4830. I'll create a MR. 4808 OPEN2,8,2,"SEEKFILE,P,R" 4809 REM LOW OFFSET 4810 O(3)=$00:O(2)=$01:O(1)=$23:O(0)=$44:T=1:GOSUB4850 4811 REM HIGH OFFSET 4812 O(3)=$00:O(2)=$3A:O(1)=$0E:O(0)=$B0:T=1:GOSUB4850 4820 REM BACK TO FIRST SECTOR 4824 O(3)=$00:O(2)=$00:O(1)=$01:O(0)=$58:T=1:GOSUB4850 4825 REM READ LAST 4 BYTES OF FILE 4826 O(3)=$00:O(2)=$4F:O(1)=$FF:O(0)=$FC:T=1:GOSUB4850:IFST<>64THENSTOP 4827 REM READ UNTIL EOI MAKES IT IMPOSSIBLE TO READ AGAIN, SO RE-OPEN 4828 CLOSE2:OPEN2,8,2,"SEEKFILE,P,R" 2829 REM WAY PAST EOF 4830 O(3)=$FF:O(2)=$00:O(1)=$00:O(0)=$00:T=0:GOSUB4850:IFST<>66THENSTOP 4832 CLOSE2 4849 DOS"U0>T":PRINT"OK":RETURN 4850 O$=CHR$(O(0))+CHR$(O(1))+CHR$(O(2))+CHR$(O(3)) 4852 OPEN15,8,15,"P"+CHR$(2)+O$:CLOSE15 4854 FORI=0TO3:GET#2,A$:A=ASC(A$+CHR$(0)):IFA<>O(3-I)ANDTTHENSTOP 4856 NEXT:RETURN In particular, these lines tell the story: 4808 OPEN2,8,2,"SEEKFILE,P,R" 4850 O$=CHR$(O(0))+CHR$(O(1))+CHR$(O(2))+CHR$(O(3)) 4852 OPEN15,8,15,"P"+CHR$(2)+O$:CLOSE15 First, open the file. THEN, open the COMMAND CHANNEL with the "POSITION" command. O$ is the concatted four-character representation of the file position. Kinda like "Base-256" notation, a Commodore I/O thing. $00 01 23 44 is ... let me get my calculator... no I'll just use Perl... position 74,564. I'm actually not sure I can DO this in C... ah sure I can... I can shove anything into a char array. It's up to the machine code to interpret it, who cares if there's a zero in there. OK.
    1 point
  10. Ok, I think I came to a bit of a conclusion. I was thinking what does disturb me the most on Video editing on Linux. Most of it is actually long videos, and video capture. Long videos, actually I don't do so much... And video capture is a different program alltogether. So maybe Flowblade on Linux is fine for now. It works, it does the job. Some long videos are a bit tedious to edit, but most of my videos are not that long. What I will swap though, is using my Windows PC for footage capturing. Since the software I found there in my arch Linux, needs more CPU then my Linux Laptop can muster. I found out the GameBar in Windows11 is pretty cool. That said, I might still swap the editing of videos themselves at a later date. But probably I want to have clear to myself exactly what features I am looking for, since right now in my head it's more or less "Flowblade, but on Windows" Thanks for the inputs so far guys!
    1 point
  11. Nothing definite. As it says in the end of that video, there are still some software issues to hammer out before they go to beta testing.
    1 point
  12. Abomination! But, you know, in the fun way.
    1 point
  13. Seeing this post about Dan Werners VIC: he apparently ported KERNAL to Atari XL machines: https://github.com/unbibium/atari64 Fascinating. Thanks to Thom Holwerda of osnews.com to bring this to my attention.
    1 point
  14. Yeah, if we already have an MCU working the power circuit, maybe a larger chip with more GPIO pins could be used to read the keyboard and mouse. I'm a little worried about the "the keyboard only works at 2MHz" thing going on right now. Designing the I/O subsystems so that they are clock speed dependent is a bad idea...
    1 point
  15. Not only was the PS/2 ports in the PS/2 computer read and written to by a microcontroller, the IBM-AT predecessor to the PS/2 was. My inclination would be to go truly retro and access the ports the way they were originally accessed back in the 80s. Now, AFAIU, the Intel part that they used back then is no longer in production, but 8bit microcontrollers that can do the task are, so go with that. I am NOT saying this JUST to free up more GPIO pins in the VIAs ... oh no! But if it DOES free up more GPIO, that would be cool too.
    1 point
  16. I figured the thread was due for post-script of sorts.... call it something of a denouement to our little adventure. (Also, I forgot to mention: If anyone sees any typos, errors, or unclear/confusing things in any of the above posts, please message me so I can fix em). On reflection, it seemed only right to take all those optimizations we made for our X16 conversion of this program, and backport them to the original Plus/4 platform in order to see what they accomplish. How much can we improve from the Plus/4's original 2 hours and 42 minute plotting time?! Well, here's the listing and outcome, as reflected in a couple screen shots from 'plus4emu': The result on the Plus/4 was actually really good ... it went from a 2 hours 42 minutes plotting time, down to 1 hour and 37 minutes! Not too shabby. You might notice I added one more optimization on the Plus/4 version, which I've sort of called out in purple in the listing above. Bonus points for anyone who can both (a) figure out what the heck I'm doing there; and (b) hazard a guess as to why the tweak provides a tremendous speed improvement on the Commodore Plus/4, but actually TAKES LONGER when added to the fastest X16 version posted in this thread above. Moving on, my last post mentioned that my college aged daughter threw down the gauntlet and challenged me to try and covert this routine to Python, which is her preferred language for all her scientific / lab / analysis stuff at school. Well, she kept pestering, and wasn't about to let me off the hook. So I downloaded a fairly all inclusive Python setup she suggested (Anaconda some such with an IDE called Spyder) and gave it a shot. Only problem: I have no genuine expertise in Python. I played with it a bit in 2006 or so just because it was included to run some bloatware on a computer I bought. So be sure, I can look at a Python program and know pretty much what its doing... but I don't 'know' Python by any stretch. But... with the help of google and the excellent reference guides from the official Python site and a few of the libraries I used, I was ultimately able to cobble something together over the past few evenings. The result was that I got Python to spit out what appears to me to be a pixel-for-pixel correct (comparing with the X16 and Plus/4 versions) output. There aren't any Python specific optimizations because I frankly would not even know where to begin. And besides, generating the image below took only seconds on the OLD (circa 2012) Core i3 machine I used for the project anyway! For what it's worth, when I emailed a copy to my daughter to say "ok, I did it, quit bugging me about it," she responded by saying (of my Python code): " um... that's not really how you are supposed to do Python..." She also accused me of not having any 'class' or something! Yes, I know she wrote 'classes' -- but tend to dislike the 'abstraction for abstraction's sake' object oriented mindset. Also, this really didn't need it and, in my view, probably would not have benefitted. And anyway, 'get the hell off my lawn!' For now, all I wanted was to cause Python to produce a 'proper' output. So I'm calling this good enough. Cheers!.
    1 point
  17. I just had to share a find on Amazon, in case anyone else happens to like these sorts of things! I was looking for a 2.5 drive enclosure, nothing fancy, just for some file swaps. I have docking stations, just wanted something smaller. Then I ran across this... https://www.amazon.com/ORICO-External-Enclosure-Transparent-Compatible/dp/B08DSWKRQC/ So, I ordered it. Even if it's not the fastest, as long as it works, I will be happy! The nostalgia is real with this one. haha I was also looking at this one too, but it's bigger than I wanted. Still may look at it in the future, becasue, NES! Also, RetroFlag makes great cases. I own 4 of their Pi cases now. https://www.amazon.com/GeeekPi-RETROFLAG-Cartridge-Enclosure-Raspberry/dp/B0919CTSJT/
    1 point
  18. Well, it arrived! Dropped a 240GB SSD I had lying around in it, after taking the ugly sticker off of course. So far so good. Looks cool, seems to work good. Not bad $12 enclosure.
    1 point
  19. Thanks all, Mac or Linux is not an option for me right now. I have them both, but they're not having the CPU/Memory as my windows PC has. @ZeroByte for Linux I worked with flowblade. It does crash now and then, but not often enough to be a nuisance. But it has many features, and filters. Not so many transitions though. Other than that on Linux I've seen Kdenlive being compared to flowblade. Not sure which to go for yet though, I don't like the subscription based softwares too much (mostly out of principle I think, but still).. No keen for Adobe, if I do Adobe, I'll do it on my Mac, not my Windows, Adobe seems to me to be better on Mac... (but that's just a feeling so far) Probably I will be trying out in the weekend some of the alternatives mentioned
    1 point
  20. Tom adds an additional note about changing directories:
    1 point
  21. https://www.popularmechanics.com/military/a29539578/air-force-floppy-disks/ is an interesting story about how 8" disks were still used until just a couple years ago for military applications!
    1 point
  22. I have thought about this in the past and it still amazes me how far we have come in my lifetime. I can remember using 8" disks on a Radio Shack TRS-80 Model II back in elementary school. Both my Math and Science teachers had them. Circa 1980'ish. Though I never owned one myself, I just remember thinking it was so cool when I got my first 5.25" drive on my TI-99/4A. How times have changed. To be honest, I sometimes miss physical magnetic media, and their sounds. Also, who can forget the iconic IMSAI 8" floppy drive from WarGames! I remember wanting one so bad, even though it was technically outdated by the time the movie came out. I still thought it was cool!
    1 point
  23. I was up until 4:00AM doing a Google "deep dive", looking anywhere and everywhere for any pictures or mentions of anything like that C64, and I haven't found anything more. However, in the process, like Snickers said, I am seeing things I haven't seen in decades, or never knew about to begin with! Sometimes, the journey is just as rewarding, if not more so, than the destination.
    1 point
  24. Hi guys, well I ended up buying this strange monster and I have to say I am none the wiser. The person who said above that it looked like both parts were identical was correct. The thing that confuses me the most is those parts are definitely injection moulded. And in my experience back then to create tooling for a part like this that fits perfectly with the Commodore 64 would cost the equivalent of around $20,000 today. It just isn’t conceivable to me that somebody would do that for a homebrew project. This must’ve had a commercial release or commercial application. There must’ve been many of them manufactured. Here are some more photographs I took as well as the original ones from the eBay listing. https://photos.app.goo.gl/WZoiVeNmhvxmH9oC9 I have asked Bil Herd and David Pleasance and so far none of them have any idea. Does any of the shed any light on the mystery for you guys? Needless to say I’d love to make a little video about it but it will be a shame if there was no conclusion. Thanks!
    1 point
  25. I promised this thread, so it's time for me to deliver. I said that I would use two 65C02s on the motherboard in an homage to the Fujitsu FM8/7/77 series. That isn't strictly true. I plan to use one 65816 and one (possibly two) Hudson HU6280s. I have several reasons for this: 1: Addressable memory space of 2MB 2: Several powerful mass move instructions (Transfer Alternate Increment, Transfer Increment Alternate, Transfer Increment Increment, Transfer Increment None, and Transfer MPRI Accumulator especially). Why do I chose this particular chip? Because it was on the open market, and used for more than just the NEC PC Engine/TurboGrafx-16. Other applications for the chip include vending machines, jukeboxes, cash registers, electromechanical games (mostly skill cranes, bowling tables and skee-ball machines), and several arcade games by Banpresto and Data East. This (theoretically) makes it an off-the-shelf chip in the Spirit of Woz, at least at the time (Mid Eighties-Early Nineties). With regard to graphics modes: Pixels shall be grouped into vertical sets of seven pixels, arranged in horizontal rows. For the purposes of memory address segmentation, the base increment of pixel set rows is 4. Perhaps not so coincidentally, this results in a character address 4x7 pixels in size, or one pixel in either dimension smaller than the smallest possible readable alphabetical font. Each byte thus maps to 7 single bits of pixel depth, plus the "pallet bit" used by Steve Wozniak to gain extra pixel bit depth. Each Pixel Row set will then be grouped into "Tiles" nine sets horizontal by four vertical sets, or 36x28 pixels. This means that at a projected "Medium" resolution of 288x224, a 7-bit pixel depth would take up 63K, with an actual theoretical color depth 16,384 (128 CLUTs of 128 colors each). In practice, this number is bound to be a little smaller, as most graphics artists will not be so confident in their color needs not include transparency in a majority of their CLUTs. And of course, simply defining those CLUTS will require a specific stretch of at least 20K of Video RAM, and lots and lots of coding. Well, nothing is free. At my planned 7:9 aspect ratio, and taking into account matching spare Video RAM for CLUTs, fonts, and BOBs, a full memory map would result in a 1152x896 display at maximum bit depth per pixel. However, that would translate to a pixel clock higher than the Hu6280 could accommodate on its stock clock. Without a sufficient steady supply of regular new production or new-old stock, I am loath to test any overclock above the stock 7.16 MHz. It looks like it's getting pretty late. I'll continue this at a later date. Questions? Comments? Suggestions? Flames?
    1 point
  26. DAI is a computer, British designed made in Belgium. It had a graphics system where the first 2 bytes of each line specified how the following data would be interpreted graphically, or if text the next 8 lines I think. It’s not well known, but it’s different.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use