Jump to content

a8isa1

Members
  • Content Count

    1,616
  • Joined

  • Last visited

Community Reputation

718 Excellent

About a8isa1

  • Rank
    Stargunner

Profile Information

  • Gender
    Male

Recent Profile Visitors

27,316 profile views
  1. This was me not understanding the need for enabling SPIFFS in the Arduino IDE. I don't know if it was the default or if I inadvertently set it to "4MB (no SPIFFS)". No file system means no place to store the config. This is not a problem for someone programming the ESP8266 using the supplied .bin. -SteveS
  2. Found the reason to some of my problems with the Zimodem. My simplistic cable left CTS (on the NodeMCU dev board) unconnected. The ESP8266 build, when compiling v3.5, has CTS-RTS as the default flow control. The firmware didn't like CTS unconnected and didn't always recognize keystrokes from the Atari. I changed the default in the source to flow control disabled. Now the Atari will always communicate with the Zimodem and the AT&H command now works. AT&U and AT&U6502 still don't allow OTA updates and cause an exception error and restart of the Zimodem. I think I'll change the source (locally) again and enable XON-XOFF handshaking as the default. One other problem I ran into is configuration changes weren't permanent. Most annoying of these is the SSID and Password for my router. Here's a tip. If you use the Arduino IDE to compile and upload Zimodem firmware to the ESP8266 don't forget to enable SPIFFS (SPI Flash File System). The option is under Tools --> Flash Size. You won't be able to write the config, AT&W, without SPIFFS. -SteveS
  3. Hi, I don't want to divert long from the topic of this thread but I was wondering if you have successully used the latest v3.5 Zimodem sketch? I've successfully compiled and uploaded it to the Nodemcu dev board (v0.9). I can see the boot message but it doesn't accept any keystrokes. When I upload the included .bin it works fine, but that's v3.4. I'd like to try to add RVerter logic right in the firmware. Regards, -SteveS [EDIT] And of course I plug it in and now it works. Yesterday it didn't. Well, I can make connections. AT&U (update firmware) generates some sort of exception error. AT&H (help) returns only "ERROR"
  4. Sounds like you have a 5.25" drive and PC suitable to use it. Also sounds like you have some/all double density disks. If you have the ability to install MS DOS and Win 9x then give Hias Reichl's WRITEATR a try. Back about 15 years ago I ported all my DD disks from an ATR8000 to ATRs using a 5.25" HD disk drive. Takes about 50 seconds each (for single sided disks), IIRC. I might have that wrong. Call it a minute. It's fast. I'm pretty sure WRITEATR works with XF551 disk. I can't speak for US doubled drive's disks. Hopefully Hias, himself, will chime in Anyway, if the old PC is at hand, WRITEATR is worth a quick try. -SteveS
  5. At first I only spotted the missing video and SIO cables and the 80 column display. My guess for the display would be VGA. I can't tell if the borders (lower left corner) are double line character graphics. I think they are. This would indicate a PC character set. Some 3rd party interface or a modification would be needed to use 3.5" diskettes. XF551 with ROM change? ATR8000. Percom. Black Box with Floppy board. Etc. The black diskette at the bottom is clearly an HD diskette. I don't believe there were any A8 disk interfaces that can utilize 3.5" HD floppy disks. HD hole isn't covered to force double density mode. I don't this trick worked well anyway. Not a mistake per se but I never used side perforated paper for program listings. That way I could also use the back for a later listing. (paper was expensive!). XE is heavily yellowed. Much more than it would be if this were a period correct photo. -SteveS
  6. You might be surprised to learn that my NTSC palettes exist because I was attempting to get Altirra's colors to look like my real 800 with a scan converter and a CRT VGA monitor. They are intentionally wrong. Decades ago I read an Atari 800 field service note that describes adjusting the color trim pot so that hue 1 and hue 15 appear equal on the screen. That's how my 800 stands to this day. I eventually learned that this type of adjustment was incorrect. However, I have no way to accurately put any of my Ataris back to the factory setting. Moving years ahead to the release of some version of Rastaconverter. Since my 800 is out of adjustment then the colors rendered in picture conversions of course would not align. To my surprise there wasn't a position for the pot that would make the colors align. I assumed my 'scan converter' (basically a cable TV set-top box designed for a desktop computer) and CRT monitor combo were way off the mark with respect to the NTSC specification. I decided to view Rastaconverter picture on emulators only. Some time later I learned that I could adjust Altirra's colors to resemble my real Atari. This in turn got me to wonder if I used the now custom Altirra palette in Rastaconverter if the colors might look correct on my 800XL (by this time the 800XL was my daily driver). The colors were considerably better. Almost totally aligned. I tweaked the hue starting color and hue angle. My palettes are set where I stopped tweaking. Atari Blue-green and cyan(ish) hues still don't seem to line up correctly. The other colors are very close. The saturation levels in the palettes don't affect what a real Atari can output but they subtly affect choices made by Rastaconverter during the processing. -SteveS
  7. ./fastbasic-fp -v reports the following: FastBasic 4.1-b3 - (c) 2019 dmsc -SteveS
  8. I received this error when compiling your example. ./fb pmtest1.bas pmtest1.asm Compiling 'pmtest1.bas' to assembler 'pmtest1.asm'. pmtest1.bas:32:4: parse error, expected: statement or variable assignment, integer variable, variable assignment DLI <--- HERE -->[ POKE @HPOSP0, PEEK($600) : POKE @HPOSP -SteveS
  9. I'm beginning to regret starting this thread because now 3 people, myself included, have received damaged or defective screens (1 screen each). The spare screen has saved the situation twice. That's not good enough. mimo, please use banggood.com's app (or whichever method you prefer) and request a replacement. Don't let it slide. Perhaps they will remedy the situation permanently. I've mentioned this already but if you do use their app if banggood requests additional information via email it's best to reply via email. Using the app a second (and third) time only got me the same form email. Two people recommended banggood to me and have been using them from some time which is why I gave them a try. Since banggood did resolve my issue I'm still open to using them. I have to go on my own experience(s). If I have another issue I'll probably move on. I personally don't have a favorite vendor yet. -SteveS
  10. $(...) function is documented as the inverse of ADR(). Can build a string at a memory address. -SteveS
  11. ah! didn't know about not needing the DIM. Thanks. The other two lines are an example from the manual. Works fine as typed. -SteveS
  12. I recently learned of FastBasic. I tried following an example from the manual but get a "parse error" with 'X' flagged in the DATA statement. What am I doing wrong? DIM X(10) BYTE DATA X() BYTE = 2, $41, $42 ? $( ADR(X) ) Loving the speed of the example programs. Thanks for this, dmsc! -SteveS
  13. After many attempts at these it's time to move on. [NTSC] [PAL] I took shot at this picture as well. I wasn't able to disguise the LINE dither nor process out the errors (right cheek). On the Atari the image looks better a couple feet back from the monitor. [NTSC] These were processed using my saturation 50 palettes. If viewing in Atari800 emulator you'll need my palettes (see my sig) or in Altirra bump the saturation to 50 for the PAL image. For NTSC there's a bit more tweaking. Saturation also 50, hue start is -44, and hue step 24.1, On real hardware you might need to boost saturation of your monitor some but the colors are achievable. -SteveS a8isa1_chameleon2.xex a8isa1_chameleon2_PAL.xex a8isa1_mouth.xex
  14. Is the screen completely white? If there is a faint crosshair in one of the corners then you are seeing the calibration screen but the colors are inverted. If that's not the case I don't have a solution for you. Sorry. However, you can test your screen with the arduino IDE and the MCUFRIEND_kbv library. The examples include screen and touch panel tests. You can obtain the library from within the Arduino IDE. I think you'll find it under Sketches-->Include Libraries. Scroll to the top of the pull down list and click Manage Libraries. Search for "MCUFRIEND" and install the one named MCUFRIEND_kbv. The examples are in the libraries folder. With linux the folder would be in ~/Arduino/libraries. I don't know where the folder resides for the Windows version of the IDE. The example, TouchScreen_Calibr_native, is a good one for a quick test. It will test the touch feature and display enough for you to evaluate your screen. Text should be white on a black background. Be aware the ILI9338 screens apparently don't answer with a valid ID, to the program's challenge. Each of the examples need to be edited. Usually each example has a bit of code similar to this, IF (ID == 0xD3D3)... Sometimes the value being tested is different. Following the test sometimes guess_ID gets assign a value to force the panel's ID. You want to change this value to 0x9338. In the case of the calibration sketch the ID is only read and tested. Just below that test you want to add the following line. ID = 0x9338; Upload the sketch (to your Arduino UNO) Good luck. -SteveS
×
×
  • Create New...