+JAC! Posted April 12, 2015 Share Posted April 12, 2015 just looked at it with a font editor, so I might just change it... atari.fon.zip Which editor do you use? Being able to directly create .FON will simplify the project setup. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 12, 2015 Share Posted April 12, 2015 Which editor do you use? Being able to directly create .FON will simplify the project setup. I used a program called Fony http://fony.en.softonic.com/ Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 15, 2015 Share Posted April 15, 2015 Here's a more accurate Escape Character in the font. I shifted the "E" left one pixel and the "c" right two pixels... atari.fon.zip Remove ".zip" from filename... Quote Link to comment Share on other sites More sharing options...
+JAC! Posted April 16, 2015 Share Posted April 16, 2015 (edited) Thanks. I spotted some more wrong pixels. Latest version is now checked in to the Git repository where Eric and I are working on the new version of DIS6502. https://sourceforge.net/p/dis6502/git/ci/master/tree/src/atarisys/atari.fon What's the program in the screen shot btw.? Edited April 16, 2015 by JAC! Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 16, 2015 Share Posted April 16, 2015 (edited) That's the ATR Tools app I working on. Screen shown is the Sector Display/Editor... What other characters have bad pixels that you have spotted? Edited April 16, 2015 by AtariGeezer Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted April 16, 2015 Share Posted April 16, 2015 (edited) Maybe I'm a heretic, but this is a windows tool, why bother using an Atari font in the first place? Just switch it to a windows font that doesn't have the limitations, plus it will look more "windowsy". Could be I don't understand some requirement though... I suppose for certain display items you want an Atari font, but not all. Edited April 16, 2015 by Shawn Jefferson Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 16, 2015 Share Posted April 16, 2015 If you need to display the entire ATASCII set - including all the control characters - it's logical to use the Atari font. 1 Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted April 16, 2015 Share Posted April 16, 2015 Yes, I know... I always found using DIS6502 sort of "jarring" though due to the use of the Atari font everywhere. IMO, it would have been better to use it only where required. But of course, beggers can't be choosers and I'll take it however it's made. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 16, 2015 Share Posted April 16, 2015 Oh I see what you mean: just use the Atari font in the memory dump window. I kind of agree: Courier New in the source window, etc. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 16, 2015 Share Posted April 16, 2015 Maybe I'm a heretic, but this is a windows tool, why bother using an Atari font in the first place? Just switch it to a windows font that doesn't have the limitations, plus it will look more "windowsy". Could be I don't understand some requirement though... I suppose for certain display items you want an Atari font, but not all. To view an ATASCII / Basic File or Sector Data, you need the Atari Font anyway... I only use it in a few other places to match the display where used... Quote Link to comment Share on other sites More sharing options...
marcokitt2000 Posted April 16, 2015 Share Posted April 16, 2015 Hello Finaly there's programing in progress. The dis6502 i like this tool many year's and hope there will some futher and other stuff. I hope that jump or adresses Lxxxx has sometimes problems. Keep the good work. Greetings Marco Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted April 16, 2015 Share Posted April 16, 2015 Courier New in the source window, etc. Or some other fixed-spacing font of your choice; let it be selectable. 1 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted April 16, 2015 Share Posted April 16, 2015 (edited) Or some other fixed-spacing font of your choice; let it be selectable. The point is that not using the Atari font in turn causes trouble with .byte/.sbyte/.. statements. There you can arbitrary ATASCII characters as part of the source. And while disassembling original Atari code, that's also what you want. Using something else will screw it up because there many obstacles when using fonts, because for example also in Windows there control characters in the standard fonts. And using different font for the different inner windows is also not option, as it'll make layouting far too complicated. And above all: Making is selectable and persisting a setting like this would require a lot of effort. Remember the source started as 16 bit Windows app and persists settings a manually binary serialized files. Adding a single boolean setting there (thereby causing a new serialization version) will take >1d. So everybody with C knowledge is invited to join the efforts :-) Edited April 16, 2015 by JAC! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 16, 2015 Share Posted April 16, 2015 The point is that not using the Atari font in turn causes trouble with .byte/.sbyte/.. statements. There you can arbitrary ATASCII characters as part of the source. Does anyone actually still do that? It makes porting code from one assembler to the other very difficult. Non-printable characters in BYTE statements should be specified numerically anyway if the code is to be remotely portable. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted April 16, 2015 Share Posted April 16, 2015 Hehe, I knew you'd say that. And yes, I do it, at least during the analysis phase of a disassembly. And I definitively want it in the dump window. But see my other comment on the layout. Using a different font in only one of the Windows causes hassle I want to avoid unless somebody else takes care of it. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 16, 2015 Share Posted April 16, 2015 Heh, OK. Aside from the font issues, it would be nice to have the option to completely banish non-printing characters from the actual output listing when you're done looking at them. No argument about the dump window, though: they're obviously needed there. Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted April 17, 2015 Share Posted April 17, 2015 If mixing fonts in the disassembly window is not possible, than it doesn't make much sense. I'd assumed that you could display multiple fonts in the same window, but I've never done any windows gui programming. Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted April 19, 2015 Share Posted April 19, 2015 First, a very quick solution... just hook up a secondary monitor, specifically for debugging, and console-based stuff, set that monitor to a low resolution, and your problem is solved. If you don't have a dual-output video card, just pick up a very cheap PCI video card, specifically for this setup. Next, why not use a cross-platform GUI toolkit for the front-end? TCL/TK, or Python with TK (Tkinter) would end your pain, quite quickly. I used to do a lot of TCL/TK programming, and it is a great, fully cross-platform language. Nowadays, most jobs want Python, though, so if you know neither, you may as well start out with Python. TK is just nailed onto it, so it's the same. TK lets you put together full GUIs in very short order. TCL allows for complete integration with your existing C/C++, Java, and assembly. It really is a shame that it's fallen out of fashion, especially since it has the "Starkit" functionality available to it. In any case, you should look into TK & some other language, as a new GUI front-end. Active State is the place to go for Windows, and everything that you need is available for Linux, though your distro's package manager. The beauty of TCL/TK is that you write the code once, and have a full GUI on Windows, Mac, and Liunux/UNIX. No time gets wasted on platform-specific bs. Good stuff to check out! 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted April 19, 2015 Share Posted April 19, 2015 I agree with the Python plus GUI toolkit idea. However, instead of TKinter, I would suggest QT4 (or QT5), or the workalike PySide. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 19, 2015 Share Posted April 19, 2015 I doubt Jac! wants to rewrite the whole thing from the ground up in a different language merely in order to mix fonts. I think the idea is to make measured improvements to the UI and functionality without having to completely rebuild the thing from scratch. 1 Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted April 19, 2015 Share Posted April 19, 2015 I doubt Jac! wants to rewrite the whole thing from the ground up in a different language merely in order to mix fonts. I think the idea is to make measured improvements to the UI and functionality without having to completely rebuild the thing from scratch. Since most people haven't worked with TCL/TK, it might be plausible to presume as such... however, you can build an entire professional-looking GUI for Windows application in an afternoon. Your existing code for the meat & potatoes of your program just hooks right in, you lose nothing. You then just discard the "fat" from your old Windows API calls, or whatever method that you used to display your GUI... just cut it right out of your source code. So, no, there is no "re-writing from the ground up". TCL/TK is a beautiful thing. You can then encapsulate the entire thing in a virtual filesytem, via a Starkit, and the whole project just looks like a .exe file, to the outside world. The salaries for Python programmers these days are also a beautiful thing, so, it is surely not time wasted. Learning either of them is simple, if you have a background in procedural programming & scripting. You should test it out, some weekend, you'll see what I mean. The "Expect" language variant is also super-useful. You can find everything on the "Active State" link, posted above. You'll wonder why you ever messed with any other GUI tech, after you get started with this stuff. 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted April 20, 2015 Share Posted April 20, 2015 I doubt Jac! wants to rewrite the whole thing from the ground up in a different language merely in order to mix fonts. I think the idea is to make measured improvements to the UI and functionality without having to completely rebuild the thing from scratch. Probably so. But it's more a look to the future maybe. Just throwing some ideas out there on some tools that a talented programmer like Jac might want to investigate some day. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted April 20, 2015 Share Posted April 20, 2015 Thanks for the feedback and hints. What might happen somewhere in future, is that DIS6502 is ported over to Java/Eclipse and becomes part of WUDSN IDE. Eric is also a professional Java/Eclipse programmer. But as Jon mentioned, the main purpose is to bring the existing code to life and back to nowadays standards. And in fact it's nice to see how VS/Win32 actually works - you feel much more satisfied with Java after that :-) Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted April 20, 2015 Share Posted April 20, 2015 DOH! ... There it is... The "J"-word... There is really only one really good thing about Java... & that's the End User License Agreement (EULA). It has provided me with years of amusement. Here it is, in all of it's splendor, Verse 7 of the Epic Javaeula: "Note on Java Support... Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines, or weapons systems, in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage." (Audience laughs) = ) Yes, Friends, so good that we gotta say it again! "the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage." So good that we could use it in the chorus of a song. We'll call it "The Ballad Curse of James Gosling"... It'll be great! = ) 1 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted April 20, 2015 Share Posted April 20, 2015 It just the same with C as we all know, as a SEGFAULT also clearly kills (at least the process) - they just never never had the guts to put it into an EULA 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.