Jump to content

willyvmm

Members
  • Posts

    68
  • Joined

  • Last visited

Profile Information

  • Custom Status
    mouSTer master
  • Gender
    Male
  • Location
    .dk
  • Interests
    Atari Hardware

Recent Profile Visitors

4,999 profile views

willyvmm's Achievements

Star Raider

Star Raider (3/9)

99

Reputation

  1. For some time WUDSN allows editing (Mad) Pascal .pas files. Unfortunately the integration is not finished yet or I'm not able to use that. I have decided to use Mad Pascal for my latest project. Unfortunately the "Geany" solution is not enough. No direct debugging support. So i have decided to make WUDSN bit more (Mad) Pascal friendly. The main assumption was: Quick and Easy (Dirty not excluded). 1. Create a new WUDSN project, and name it xTemplate. - The "xTemplate" name make it appearing on the end of the list almost always. 2. Define Builder for Pascal. - Project->Properties->Builders->New - [OK] - Name->Mad Pascal - Location->Enter or click out path to your "mp(.exe)" - Working Directory->Enter or click out: " ${workspace_loc}${project_path}" - Arguments->Enter or click out: ${workspace_loc}${selected_resource_path} - [OK] 3. Associate *.a65 files with MADASs in WUDSN. - Window->Preference->General->Editors->File Associations->Add.. - Enter *.a65 - Select MADS Editor - [APPLY AND CLOSE] 4. Slightly modify MADS compilation params. - (should not affect pure madas programs, and allow Mas Pascal generated files compilation) - Window->Preference->Languages->Assembler->Atari 8Bit Assemblers->MADS - In the Parameters field, enter/copy same text that is in default field, and add at the end -x -i:_path_to_your_mp_instalation_folder_/base - [APPLY] 5. Make your life easier, and modify keyboard shortcuts. - Window->Preference->General->Keys - Find "Build All"-"CTRL+B" and remove it -> [Unbind Command] - Find "Build Project" and associate it with "CTRL+B" (or any other prefered) -> click on [BINDING] field and press your desired short key [CTRL+B] - In the "when" field you should see "In Windows" - if not - just fix it. - [APPLY AND CLOSE] Done. How to use: - Make a copy of your reference project (xTemplate) - mark it on WUSDN, CTRL+C followed by CTRL+V - Give it a new name - Create a new .pas file, enter your code ... etc... - When in Your .pas file window, press CTRL+B, mp will create new file: _your_project_name.a65 - In the "Project Explorer" window (usually the most left window) mark your new project, ane press F5 (refresh) the new generated _your_project_name.a65 will apear in the project tree. - Double click on the _your_project_name.a65 file to open it. - Inspect the file And/Or mark your desired Breakpoints. - Press CTRL+9 to compile. - or - Press CTRL+0 to compile and run. In case of Altirra the BreakPoints will be activated. (afaik) - Enjoy. I have no idea if it's the best or simplest way to do that, but it works (at least for me) and i think is worth to share.
  2. Mad Pascal has a "feature" that "normalizes" path. This is not an issue under Windows, but has unexplainable behaviour under linux. I have developed a simple path, to fix that issue. Path is available on MP github. https://github.com/tebe6502/Mad-Pascal/issues/113 With that path, most mp examples compiles without issues, except fx. Mad Pac. In Mad Pac, one resource file use Capital Letters in filename. So ... I was too busy to patch this too. Instead i've renamed the file, and all references in source files. Keeping all filenames as small letters works. SO the patch is not so important. Enjoy.
  3. @mods: please move to: Atari 5200 / 8-bit Programming Thanks.
  4. As there is no full direct Linux support in Altirra nor WUDSN, i did wrote a simple wrapper script that simplifies full ALTIRRA-WUDSN integration under linux. Requirements: wine Howto: Copy the attache script to your Altirra64.exe location. Open WUDSN ide, go to: Window->Preferences->Languages->Assembler->Atari 8-bit Assembler->Altirra TAB Enter path to the wrapper script instead of altirra64.exe. (see attached picture) Enjoy Your new Linux Dev Setup. AltirraLinuxWrapper.sh
  5. HI again. Finally i got a fully working display, so i can show You that is really working Enjoy.
  6. Compiled diagnostic software has been attached to the blog post as well as link to source code repository. If your screen is blank, and is a mcufriend type, likely is just broken. You may use serial console (arduino serial console) to get some debug output. https://retrohax.net/atari-800-xl-refurb-sdrive-max/ w.
  7. @E474 it depend on Your difficulty definition. Compared to blinking LED id Rocket science. Compared to Apollo guidance computers od easy. Yo have to know how to read datasheet, how the software is working, how the hardware isvworking, and what to expect. Then is easy. I have no idea how mamy LCD types are sharing same layout and can be used with Arduino. @mamejay if Your LCD is working with original firmware, then it is not ili9325. The ili9325 seems to be an early version of lcd controller family, and is not compatible with newer chips. (Also more difficult to program). I have dissected some of the mcufriend lcd's, and there is possibile to mount at least 5 different LCD on PCB that are almost identical. The Only way to identify your lcd chip is to run a diagnostic software. Another problem is quality. 2 of 4 was broken when arrived. Only white screen and problem with reading id. One of them has identified itself as Renesans R61xxx (afair). So... It's lottery.
  8. HI. Some time go my friend (Drygol/Lamers) has bought a 2.8" display ... but received a 2.4" mcufriend based on ILI9325 chip. As the firmware do not support this display, I have done "driver" that support this lcd controller. Link with compiled firmware and link to source code that support this LCD is available here: https://retrohax.net/atari-800-xl-refurb-sdrive-max/ Pull request is pending, and hopefully will be merged with official firmware soon. Best Willy
  9. Hi. Thanks. Again, great job. I just started to do the same, ... but i will only complete the data. I did analyzed only MFM mode, so the following covers only ED and DD. Following FDC279x datasheet, all gaps ($4E bytes) , except one, between IDAM and DAM, can be shortened to be as short as 2 bytes. But, it is not recommended because of PLL synchronization. And the only critical structure is sector layout. All firmwares, are creating identical sector layout (using different software). IndexDatamark is optional, and is not required. SyncMarks, are special bytes, wroten with missing clock bit - its FDC special feature, "commands" F5 and F6. F5 "command" write A1 byte with missing clock bit. (pre DAM sync mark) F5 "command" write C2 byte with missing clock bit. (pre IndexMark sync mark) F7 "command" write 2 bytes CRC, calculated by Hardware In every case sector layout is identical, and is achieved by using different software tricks. MFM sector layout: 12 x $00 3 x PRE DAM sync (F5 "command") 1 x $FE (IDAM) 1 x Track number 1 x Side number 1 x Sector number 1 x Sector Length ($00 = 128, $01 = 256, $02 = 512, $03 = 1024) 2 x CRC (F7 "command") 22 x $4E (GAP - may not be shorter) 12 x $00 3 x PRE DAM sync (F5 "command") 1 x $FB (DAM) xx x DATA (128 or 256 bytes of data, it could be also 512 or 1024) 2 x CRC (F7 "command") 24 x $4E (PostData Gap) (this varries, and is sometime located in leadin area, usually 24 bytes.) All firmwares are using long track LEAD-IN, that is overlapped by last bytes/sector leadout, it is (i guess) to erase any remaining data on track. Thats, not true for xf551 - because of using Index hole. IndexMark, and PreIndexMark Sync are optional, and not required by FDC. I think this should help to explain all. Btw. I could not find any info, that 1050 is not supporting $4E/$4F commands.
  10. Thanks. It makes sense. I took a qiuck peek into 1050 ROM, and can say that info provided in link from 1'st post is absolutelly fabricated... maybe it match its bigger brothers drives (ST) but not 8bit, specially 1050. So i'll have to examine 1050 ROM, and TopDrive (easiest) ROM to find the proper track layout. or Just hook logic analyzer to my 1050 and have some fun
  11. Hello folks. I need to know a logical structure of DD atari floppy track. I found some info here: http://www.ataripreservation.org/websites/freddy.offenga/megazine/ISSUE6-FDTECH.html.. but it seems that is somehow wrong. As SD and ED looks reliable (SD/ED uses ca. 97% of theoretical capacity.), DD track exceeds theoretical limit of bytes on the track. Theoretical capacity is 6510 bytes/track for MFM encoding, alnd half of that for FM encoding. for DD track: 51+18*(112+256)=6675, its 165 bytes more that theoretical capacity ... Is there someone who can explain that? Or Could someone upload Kyroflux image of DD track ? (perfectly would be get it as MFM decoded stream) Or any other idea ? Br. willy.
  12. No. Sorry. Buyt you can send me an email and I will put you on a list.
  13. SOLD OUT. For now. There will be some more after easter, but unfortunatelly the price will be higher. Any question? Just ask me.
×
×
  • Create New...