Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Rod Pemberton Newsgroups: comp.lang.forth Subject: Re: DurexForth v1.5.0 Date: Thu, 7 Jan 2016 03:14:53 -0500 Organization: Aioe.org NNTP Server Lines: 23 Message-ID: <20160107031453.7bc31f5d@_> References: <66f692be-a60d-4449-bb49-0ffd2e081bd1@googlegroups.com> NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Newsreader: Claws Mail 3.13.1 (GTK+ 2.24.10; x86_64-unknown-linux-gnu) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:44654 On Mon, 4 Jan 2016 15:08:59 -0800 (PST) Johan Kotlinski wrote: > Unfortunately there is one part of the standard that seems really > like a bad idea for me to follow, so I would like to pass in some > criticism here. It is the enforcing of ASCII that sits bad, since the > C64 naturally uses PETSCII. It bothers me why the Forth standard, > which is so flexible in many other areas, should be so specific about > this? The C standard does well without this requirement. Well, I think the best solution is to just use PETSCII and translate it, if you need code portability. However, if that's unreasonable, you could reprogram the graphics character set on the C64. That's how all those old C64 "graphics" games worked, e.g., Ultima. So, you could load a different set of character images, i.e, images for ASCII and so display ASCII. A simple 256 byte lookup table would translate keyboard input. Rod Pemberton