Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 2,837 of 4,675    |
|    James Harris to wolfgang kern    |
|    Re: Look back to "just for the H@ck"    |
|    18 Jul 17 10:44:40    |
      From: james.harris.1@nospicedham.gmail.com              On 18/07/2017 09:59, wolfgang kern wrote:       >       > James Harris asked:       >       >> I wrote:       >>> Martin Str|mberg wrote:       >>> ...       >>>> So you decide the rules and tell and show us (if you want).       >>>       >>> Thanks, I thought real needs caused this restrictions.       >       >> As someone who has seen the various attempts at writing a decoder I am       >> not sure what the goal is. I get it that you have been producing code       >> which uses bytes in the ASCII printable character set but there are       >> lots of questions.       >>       >> What is the basic requirement?       >       > the challenge was/is to create the shortest possible BASE64 decoder with       > transferable text to be renamed as a xxx.COM and be executed in DOS.              Thanks for the explanation, and those below. Weeks of mystery are now       resolved. :-)                     >       >> What are the initial conditions, i.e. what do you know about registers       >> at entry?       >       > know register in DOS.com files are SS=DS=ES=CS SP=FFFE or less [SP]=0.              OK.                     >> What's the minimum number of bytes you can count on before you might       >> get to a CR or CR/LF?       >       > I think we agreed on 64-characters/line but it can be more or less or       > even reflown during transfer. So we got to skip any space, tabs CR/LF.              Skipping later CR or CR-LF is one thing but I was thinking that having       either of them potentially inserted in the early bytes of the decoder       code would be very tricky.                     >> Can you overwrite the original text with the decoded version?       > yes.              OK. Good!                     >       >> If not, what options can be used to get memory to decode into?       >       > nothing, DOS.com is limited to ~63.5 KB. I use PSP CS:040.. for decoder.       >> In addition, I could guess there might be problems with the location       >> of the decoded code. So I guess it is meant to be started at CS:0 or       >> CS:100. Am I anywhere close?       >       > The challenge implied that the final decoded stuff starts at CS:0100 and       > run (or as additional challenge to be stored) as a .com-file.              OK. I have to say that that raises challenging issues of alignment if       the decoded output is to overwrite the input.                     >>> So my rules for such an Base64 decoder would allow ASCII 33..127 and       >>> nothing less than 386 code.       >       >> You know you want to use 8086 code really.... :-)       >       > I'm much older than 8080, but I wont enter the museum to run my code.              I remember programming the 6502 and the Z80. Happy days! But I never       went back as far as the 8080.                     --       James Harris              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca